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Currently the development and maintenance of DOD embedded software systems 
with hard real-time constraints is a very complex, time-consuming and costly task. This 
situation: can be improved by the use of adequate development methods aut powerful 
support tools. This thesis explores the development and integration of rapid prototyping 
tools for the Computer Aided Prototyping System (CAPS). CAPS supports the design 
and evolution of large, reliable embedded software systems while significantly reducing 


their associated development and maintenance costs. 


CAPS utilizes the Prototype System Description Language (PSDL) and an integrated 
set of construction and analysis tools. The integration of these tools utilizes previous 
work on their design, with partial implementations and feasibility studies for some of the 
tools. We have defined and implemented a user interface while testing previous tools, 
refining the designs of the tools and either refining the implementations or generating the 
initial implementations. The user interface provides systematic access to the tools of the 
environment to support the underlying rapid prototyping methodology. Integration issues 
include system configuration, integration testing, design modifications, implementations, 


and evolution of previously developed tools within this rapid prototyping environment. 
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I. INTRODUCTION 


This thesis describes the development of a rapid prototyping environment. This 
chapter presents a brief description of the software engineering problem and current 
methodologies utilized in software development. The Prototype System Description 
Language (PSDL), the Computer Aided Prototyping System (CAPS) and PSDL proto- 
types in CAPS are described briefly in the next chapter to provide a foundation for this 
thesis. The design of CAPS, and more detailed discussions of many of the primary tools 
in the environment are contained in successive chapters. These chapters are followed 


with our conclusions and recommendations for further research. 


A. SOFTWARE DEVELOPMENT 


The United States Department of Defense (DoD) is currently the world’s largest user 
of computers. Each year billions of dollars are allocated for the development and 
maintenance of progressively more complex weapons and communications systems. 
These systems increasingly rely on requirements for systems which process information 
utilizing embedded computer systems. These systems are often characterized by max- 
imum time periods or deadlines within which some event must occur. These are known 
as hard real-time constraints. Satellite control systems, missile guidance systems and 
communications networks are examples of embedded systems with hard real-time con- 


straints. Correctness and reliability of these software systems is critical. Software 


development of these systems is an immense task with increasingly high costs and poten- 


tial for misdevelopment [1]. 


Over the past twenty years, the technological advances in computer hardware tech- 
nology have reduced the hardware costs of a total system from 85 percent to about 15 
percent. In the early 1970s studies showed that computer software alone comprised 
approximately 46 percent of the estimated total DoD computer costs. Of this cost, 56 
percent was devoted specifically to embedded systems. In spite of the tremendous cost, 
most large software systems were characterized as not providing the functionality that 
was desired, took too long to build, cost too much time or space to use, and could not 


evolve to meet the user’s changing needs [1]. 


Software engineering developed in response to the need to design, mmplement, test, 
install and maintain more efficiently and correctly larger and more complex software sys- 
tems. The term software engineering was coined in 1967 by a NATO study group, and 
endorsed by the 1968 NATO Software Engineering Conference [2]. The conferees 
concluded that software engineering should use the philosophies and paradigms of tradi- 
tional engineering disciplines. Numerous methodologies have been introduced to sup- 
port software engineering. The two major approaches which underlie these different 
methodologies are the waterfall model [3] of development with its variants such as the 


spiral model [4], and the prototyping [5] method of development. 


The waterfall model describes a sequential approach to software development as 
shown in Figure 1-1. The requirements are completely determined before the system is 


designed, implemented and tested. The cost of systems developed using this model is 





very high. Required modifications which are realized late in the development of a sys- 
tem, such as during the testing phase, have a much greater impact on the cost of the sys- 
tem than they would have if they had been determined during the requirements analysis 
stage of the development. Requirements analysis may be considered the most critical 


stage of software development since this is when the system is defined [6]. 
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Figure 1-1. The Waterfall Model 




















Requirements are often incompletely or erroneously specified due to the often vast 
difference in the technical backgrounds of the user and the analyst. It is often the case 
that the user understands his application area but doesn’t have the technical background 
to communicate successfully his needs to the analyst, while the analyst is not familiar 


enough with the application to detect a misunderstanding between himself and the user. 


The successful development of a software system is strictly dependent upon this process. 
The analyst must understand the needs and desires of the user and the performance con- 
straints of the intended software system in order to specify a complete and correct 
software system. Requirements specifications are still most widely written using the 


English language, which is an ambiguous and non-specific mode of communication. 


B. RAPID PROTOTYPING 


The waterfall model lacks automation support. Systematic support using computer 
aided tools has generally been unsuccessful for the waterfall model due to the informal 
and heuristic nature of software system design. Formal modeling of software systems 
and formal modeling of software development processes are key issues in automating the 
software design process. Systematic reuse of software or design knowledge has also 
been difficult because of the lack of specifications and explicitly recorded software 


design knowledge. 


Prototyping captures selected aspects of the proposed system by generating execut- 
able models during the requirements analysis stage of software development. Trial use 
of these models and feedback from the users are major mechanisms used to detennine if 
the defined system truly meets the user’s needs before the system is designed, imple- 
mented and tested. When the requirements have been validated, the final version of the 
executable prototype provides a skeleton version of the critical aspects of the proposed 
software system. The prototype design should be extended into the production version of 
the proposed software system. This significantly reduces the cost and time of software 


development [5]. 


( 


x 


The rapid iterative construction of prototypes within a computer aided environment 
automates the prototyping method of software development and is called rapid prototyp- 
ing. Computer support shortens the feedback cycle and introduces a degree of formality 
into the process of determining the requirements specifications. This offers a systematic 
way to rapidly tum the requirements specifications into executable prototypes which can 
be observed and tested in their natural environment. Reuse of system components in the 
process reduces the cost and effort in the iterative process. A rapid prototyping model 
[7] as applied to the requirements analysis phase of software development is shown in 


Figure 1-2. 
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Figure 1-2. A Rapid Prototyping Model 


A formal automated prototyping process requires a rapid prototyping environment 
[8]. Such an environment can provide the designer with an integrated set of tools which 
are used to design and test prototypes interactively. The requirements analyst and the 
user may both observe the behavior of the prototype and ensure that the requirements 
specifications meet the needs of the user. Rapid prototyping provides an efficient and 
precise means to determine the requirements for a software system, and greatly improves 
the likelihood that the software system developed from these requirements will be com- 


plete, correct and satisfactory to the user. 


This thesis is part of a comprehensive framework for computer aided prototyping 
which includes language support, methodological support and tool support. The com- 
puter aided prototyping system is a pioneering effort with a long term impact on the auto- 


mation of software design. 


Hi. BACKGROUND 


A. THE PROTOTYPING SYSTEM DESIGN LANGUAGE (PSDL) 


PSDL [9] was designed as a prototyping language to provide the designer with a sim- 
ple means to specify a high-level description of a software system. PSDL is an ideal 
language for a rapid prototyping environment and is the prototyping language used by 
the Computer Aided Prototyping System (CAPS). The design of PSDL places a strong 
emphasis on modularity, simplicity, reuse, adaptability, abstraction, and requirements 


tracing [5]. 


Modularity is essential for effective modification. Good modularity implies a proto- 
type which is realized by a set of independent modules with narrow and explicitly 
specified interfaces. PSDL supports this concept by means of operators and data streams. 
Two distinct operators can communicate or affect each other’s behavior only when a data 


stream explicitly connects the two operators. 


Simplicity is supported by the small set of powerful constructs provided in PSDL. 
PSDL designs are networks of operators connected by data streams. These networks can 
be represented as data-flow diagrams augmented with timing and control constraints. 
Operators in the system can represent functions or state machines. The data streams 


Carry exception conditions or values of arbitrary abstract data types. 


PSDL supports reuse through uniform specifications suitable for retrieving reusable 


components from a software base. The specification part of a PSDL component contains 


several attributes which describe the interface and behavior of the component. These 
attributes can be used to generate automatically uniform specifications for storing and 


retrieving reusable components. 


PSDL supports adaptability through its ability to make small modifications to 
modules by means of the control constraints. Control constraints affect modules in 
several ways. They can be used to impose preconditions on the execution of a module, 
filter the output of a module, suppress or raise exceptions in specified conditions, and to 
control timers. These facilities provide the means to modify the behavior of a module 


independently of its implementation. 


PSDL provides abstractions suitable for describing large systems which may contain 
real-time constraints. These abstractions include control constraints, timing constraints, 


timers, functional abstractions and data abstractions. 


PSDL supports requirements tracing by means of a construct for declaring the 
requirements which are associated with each part of a prototype. This is important 
because the prototype must adapt to the changing perceptions of the requirements result- 


ing from evaluations of the prototype behavior. 


The computational model underlying PSDL can be described by an augmented graph 
G =(V,E,T,C). V is a set of vertices. E is a set of edges. T:V->R U { © }) (where R 
denotes the set of real numbers) is a function assigning the maximum execution time for 
each vertex in V. PSDL permits bounded and unbounded maximum execution times. 
C:V->R U [| c } is a function assigning the control constraints for each vertex in V. In 


this graph a vertex represents an operator and an edge is a data stream. 









OPERATOR A 
. TRIGGERED BY SOME a,b 


10 ms 20 ms 


Figure 2-1. PSDL Graph 


Figure 2-1 shows an example of a PSDL design graph with operators A and B, and 
data streams a, b, c, d. The graph also indicates timing constraints, 10 ms for A and 20 
ms for B. Control constraints are provided for operator A. The intended meaning of this 
specification is that operator A receives input data on data streams a and DB, processes the 
data within 10 ms, and outputs data on data stream c. Operator B receives input data on 


data stream c, processes the data within 20 ms, and outputs data on data stream d. 


Operators represent functions or state machines. A function produces output whose 
value is solely dependent upon the input values. A state machine produces output whose 
value depends upon the input values and on internal state values representing some part 
of the history of computation. Operators can be triggered either by the arrival of input 
data values or by periodic timing constraints which specify the time intervals for which 
an operator must fire. PSDL operators are atomic or composite. Atomic operators 


represent single operations and cannot be decomposed into subcomponents. Composite 
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operators represent networks of operators and data streams into which the operators may 
be decomposed. Operators are also either periodic or sporadic. Periodic operators fire at 
regular intervals of time while sporadic operators fire when there is new data on a set of 


input data streams. 


Data streams represent sequential data flow mechanisms which move data between 
operators. Data streams are either data flow data streams or sampled data streams. Data 
flow data streams are similar to FIFO queues with a length of one. Any value placed into 
the queue must be read by another operator before any other data value may be placed 
into the queue. Values read from the queue are removed from the queue. Sampled data 
streams may be considered as a single cell which may be written to or read from at any 


time and as often as desired. 


Timing constraints are essential for real-time systems. The timing constraints 
impose an order on operator firing which is based on timing rather than on data flow. 
There are three basic types of timing constraints: 1) maximum execution time, 2) dead- 
line or maximum response time, and 3) minimum calling period. Maximum execution 
time is an upper bound on the length of time that an operator may use to complete its 
function. Deadlines apply only to periodic operators and maximum response times apply 
only to sporadic operators. For periodic operators, the deadline is an upper bound on the 
time between the beginning of a period and the time that the operator places the last out- 
put value onto a data stream during a period. For sporadic operators, the maximum 
response time is an upper bound on the length of time between the arrival of one or more 
new data values on an input data stream and the time when the final output is placed on 


an output data stream. The minimum calling period applies only to sporadic operators 
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and represents a lower bound on the time between the arrival of one set of inputs and the 


arrival of another set of inputs. 


Control constraints are the mechanisms which refine and adapt the behavior of PSDL 
operators. They specify how an operator may be fired, how exceptions may be raised, 


and how or when data may be placed onto an operator’s output data streams. 


The PSDL Grammar is shown in Appendix A. 


B. THE COMPUTER AIDED PROTOTYPING SYSTEM (CAPS) 


CAPS is a unique rapid prototyping environment which includes the ability to proto- 
type hard real-time systems. CAPS utilizes PSDL and an integrated set of prototyping 
tools. The tools are integrated through the user interface. The primary tools in CAPS 
may be divided into three main subsystems [5]. The subsystems and their tools are: 


(1) the User Interface which is comprised of: 
- a Graphic Editor [10] 
- a Syntax Directed Editor [11] 
- a Browser [5] 
- an Expert System [5] 


(2) the Software Database System which is comprised of: 
- a Software Design Management System [5] 
- a Design Database [12] 
- a Software Base [13] 


(3) the Execution Support System which is comprised of: 
- a Translator [14] 
- a Static Scheduler [15,16] 
- a Dynamic Scheduler [17] 
- a Debugger [17] 
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The Graphic Editor is a tool which permits a designer to specify the portions of a 
PSDL prototype using graphical objects to represent the system. Graphical objects 
include operators, inputs, outputs, data flows and self loops on operators. All graphic 


objects are named and may have time constraints associated with them. 


The Syntax Directed Editor is used by the designer to enter the textual portions of the 
prototype design not represented by the graphic editor and to ensure that the prototype is 


syntactically correct PSDL. 
The Browser provides a means for the designer to view reusable components in the 
software base. 


The Expert System provides a paraphrasing capability that generates English text 
descriptions of PSDL specifications. This tools permits users who are unfamiliar with 


the PSDL language to evaluate a prototype. 


The Software Design Management System manages and retrieves the versions, 
refinements and altematives of the prototypes in the design database and the reusable 


components in the software base. 


The Design Database contains PSDL prototype descriptions for all software projects 


developed using CAPS. 


The Software Base contains PSDL descriptions and implementations for all reusable 


software components developed using CAPS. 


The Translator generates high level code from the PSDL prototype which binds the 


reusable components from the software base to the executable prototype. 
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The Static Scheduler attempts to allocate time slots for the representations of PSDL 
operators with real-time constraints before the prototype is executed. If the allocation 


succeeds, all operators are guaranteed to meet their deadlines. 


The Dynamic Scheduler invokes representations of operators without real-time con- 
straints at run-time to occupy time slots which are not used by operators with real-time 
constraints. The time slots which the dynamic scheduler uses are considered as "slack 


times". Dynamic scheduling occurs during execution of the prototype. 


The Debugger allows the designer to interact with the execution support system. The 
debugger has facilities for initiating the execution of a prototype, displaying execution 
results or tracing information of the execution, and gathering statistics about a 


prototype’s behavior and performance. 


Prior to the work described in this thesis, partial implementations had been 
developed for the graphic editor, translator and the static scheduler. Designs of an expert 
user interface and a debugger had been defined. Feasibility studies had been conducted 


for the syntax directed editor, design database and the software base. 


C. PSDL PROTOTYPES IN CAPS 


PSDL prototypes are described by the designer in the graphic editor or the syntax 
directed editor. Once a prototype has been specified, the tools within the execution sup- 
port system will construct an executable view of the prototype and then actually execute 
the prototype. The execution support system assumes a syntactically correct PSDL 


description. 
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PSDL prototype components are either an operator or a data type. A PSDL proto- 
type may contain multiple type and/or operator components. All PSDL components have 
a specification part and an implementation part. The implementation part may either be a 


PSDL implementation or an Ada implementation. 


The purpose of the two different implementation constructs is to provide a simple 
means for decomposing a prototype. A PSDL prototype can be represented by a tree 
structure. The leaves of the tree are atomic level components and they contain Ada 
implementation parts. Figure 2-2 contains a simple top level graphic representation of a 


PSDL prototype. 


INPUT OUTPUT 
_———__— > 


Figure 2-2. PSDL Prototype 


If the node SYSTEM has a match in the software base of reusable Ada software com- 
ponents, then the node SYSTEM is atomic and comprises a complete description of the 
prototype SYSTEM. In this case no further decomposition is required. If a match for 
SYSTEM is not found in the software base then the node SYSTEM is considered a compo- 
site operator. In this case the designer has two choices. If the designer does not recog- 
nize a conceptual decomposition of SYSTEM then the designer considers SYSTEM as 
atomic although an Ada representation does not already exist. The designer may then 


provide an Ada implementation for SYSTEM. The Ada implementation will be intemally 
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substituted for the PSDL implementation. The prototype would then be completely 
described and is atomic. The Ada implementation will become a persistent component in 
the software base and will be matched in future sessions with CAPS. If the designer real- 
izes a decomposition for SYSTEM, then the designer will decompose the composite 
operator with SYSTEM as the root of the tree. An example of a possible graphic decom- 
position is shown in Figure 2-3. The new operators resulting from the decomposition are 


children of the operator SYSTEM in the tree structure. 


SYSTEM 


INPUT OUTPUT 


Figure 2-3. Decomposed PSDL Prototype. 


The identification and decomposition 1s recursively applied until the leaves of the 
tree all contain Ada implementations. A possible complete tree structure for SYSTEM 
can be a single node. The complete tree structure will have a depth which is defined by 
the maturity and modularity of the software base and/or the designer’s conceptual model 
of a properly decomposed system. A possible complete tree structure for a PSDL proto- 
type is shown in Figure 2-4. It has two composite operators, SYSTEM and OP_2, and 


three atomic operators OP_1, OP_2A and OP_2B. 


15 





OP_2B 


Figure 2-4. Tree Structure For PSDL Prototype. 


A particular software base will eventually contain decompositions which reflect the 
style of thinking used by its designers. It will become customized to its users as it 
matures. The reusable components which are added to an initial software base reflect the 
level of decomposition that the designers utilize in describing the systems which they 
decompose. If the designers decide to provide Ada implementations at a high level of 
decomposition then the reusable components may tend to be large in size and may gen- 
erally be very specific to certain applications. If the designers decompose the system into 
very small modules, then the Ada implementations in the reusable software base will 
tend to be very small and will more likely occur more frequently in the design of succes- 


Sive systems. 
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The evolution of the software base of reusable components reflects the designers 
preference between using PSDL and using Ada to express their own concepts of a sys- 


tem. The design database will also reflect the style of its users. 


The success of any rapid prototyping environment is strongly linked to the means by 
which the designers may describe their prototypes. CAPS provides two means of 
describing prototypes: the graphic editor and the syntax directed editor. The majority of 


the designs in the design database will eventually be in the form that the users prefer. 


The provision of two means for user input is an important human factors feature. 
CAPS does not attempt to constrain a designer to one mode of input. While visual pro- 
gramming [18] is gaining momentum in research, the designers of CAPS recognize that 
constraining a user to one particular mode of input which emphasizes just one method of 
abstraction might possibly reduce the effectiveness of the environment when applied 


across a broad sample of users. 


A current research question with regard to rapid prototyping is whether or not it is 
really necessary to design a new language specifically for prototyping, and if so, what are 


the necessary features and characteristics of the language? 


The influence of any language on the problem domain must be considered. In this 
regard, MacLennan refers us to the Sapir-Whorf hypothesis [19] which states that the 
structure of language defines the boundaries of thought. The use of a given language 
does not prevent certain thoughts but does facilitate or umpede certain modes of thought. 
This lends support to the idea that a careful choice of language can reduce the conceptual 


barriers in the design of embedded software systems. 


17 


a 


amen 


we. — 
Computer languages have evolved over time in response to the perceived problems f 
| < 


4 


é 
ne ae —~F 


of existing languages. As languages have evolved, important peo which relate t 


the design, evaluation, and implementation of languages have evolved as well. Ada has Ke 


‘ie 
| % 


been designed as a response to DoD’s need for a standard language whith provides all of 


) = 


\ 


™ 
the features we currently perceive as necessary to develop and maintain large softwaie.. _ 
f “<a 


\ 
systems. Ada contains features which were not encompassed in any: one previously 


{ 


existing language. Since our rapid prototyping environment is aimed at large, real-time, 
embedded systems, our executable prototypes must be able to be expieeen in Ada. Ada 
is a complex language which supports abstraction, information hiding, modularity, locali- 
zation, uniformity, completeness and confirmability. The complexity of Ada leads to the 
need for a prototyping language. 

The prototyping language must provide a simple yet expressive means for a designer 
to describe a system. The prototyping language must support a cost effective means to ¢ 
establish the requirements of a system. The prototyping language must support the 


features of the Ada programming language. PSDL meets these requirements [20]. 
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Il. DESIGN ISSUES FOR THE DEVELOPMENT OF CAPS 


The design and feasibility study of CAPS has been partially influenced by local 
resources, personnel and equipment. Although the primary researchers are permanently 
assigned, the secondary researchers are mostly students with diverse backgrounds who 
are able to devote only a short period of time towards development. Student contribu- 
tions have varied in methodology and programming languages used, and they reflect the 
somewhat diverse backgrounds of the many students who have been involved. The 
development of CAPS has been a long term project. The design and feasibility study for 
the implementation of the underlying prototyping language has occurred over the last five 


years, and continues to progress. 


A. CAPS SYSTEM CONFIGURATION 


The initial step in the development of our rapid prototyping environment was to 
define an interface between tools and a system configuration. The best utilization of pre- 
vious work in the design and implementation of CAPS tools was an essential factor in 
our decision. The previous development of CAPS tools utilized and assumed the availa- 


bility of a Sun Workstation. 


There were two primary methods of integration considered for the initial develop- 
ment of CAPS. One method was to define an interface which would manage a collection 
of loosely coupled tools. The second method was to define a software architecture as a 


foundation for tool integration. 
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The Sun Operating System provides the simple UNIX [21] interface of the text 
stream. The UNIX method of tool integration defines an environment which consists of a 
collection of loosely coupled tools. An advantage of this method is its simplicity. An 
environment shell program which provides the interface with the user and manages the 
communications between the tools provides an easy means to integrate new tools and to 
extend the capabilities of existing tools. A disadvantage of this method of integration is 
that it may result in multiple data components which represent a prototype. Each data 
component produced by a particular tool is most likely a partial view of a complete pro- 
totype which reflects the transformation of data performed by each particular tool. Other 
disadvantages of this method are that the interface must be modified to add or remove 
tools from the system and that the environment contains a lesser degree of integration 
granularity. 

An example of the second method of integration is the Illinois Software Engineering 
Program (ISEP) [22] which describes an open systems architecture for tool integration. 
This method defines a software bus which provides for the interconnection and intercom- 
munication between the tools within the environment. All tools communicate with other 
tools by means of a set of communication protocols specially defined for each tool. Any 
two tools may communicate which have a common set of protocols. The advantage of 
this methodology is that it is intended to support the integration of new tools indepen- 
dently of the other tools in the environment. The disadvantage of this methodology is 
that it requires the development of a complex set of protocols for each tool in the 


environment. 
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The previous work on the bottom-up development of the CAPS tools assumed the 
first method of integration. Due to this assumption and its simplicity we chose to connect 
the tools within the CAPS environment in the UNIX fashion by passing streams of data 


between the different tools. 


The system configuration for CAPS is a natural decomposition of the CAPS design. 
A system directory is considered the root of the environment with subdirectories for each 
of the tools. The subdirectories contain the required components that make up each of 


the tools and contain documentation specific to each tool. 


B. METHODOLOGY FOR INTEGRATION 


The first implementation requirement for the environment is the user interface, since 
it is the user interface which manages the tools in the environment. Once a basic user 
interface was designed, we realized that the process of integration would be a somewhat 


circular process with iterative refinements. 


The interdependence of the CAPS tools required us to simulate the functionality of 
some tools while testing other tools. We decided that the most natural tools to include in 
the initial integration process were the tools within the user interface. The directory pro- 
totypes in the system configuration simulates the storage locations of both the design 
database and the software base. We realized that the database management functions 
could be performed manually until development, integration, and testing of the databases 


could be performed. 
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A systematic approach for the integration of a partially developed set of tools was 
established which would make the best use of previous work. The integration methodol- 


ogy for the tools consists of ten primary steps: 


Step |: 
Identify, locate and relocate all of the subcomponents and products of a particular 
tool. The subcomponents were relocated to form an identifiable modular representa- 


tion of each particular tool. 
Step 2: 
Determine the dependencies between the subcomponents of each tool and to deter- 


mine how each subcomponent was intended to interact with the other subcom- 
ponents. 

Step 3: 
Resolve any naming conflicts which existed with the subcomponents of a tool or the 
data it produced with the names expected by other tools in the environment. 

Step 4: 
Determine how to compile the various subcomponents, and to determine which sys- 
tem libraries needed to be linked with each subcomponents. 

Step 5: 
Separate the functional components of a tool from the partial views of a prototype 
which were used by the previous developers to test their tools and to load these sub- 


components in the proper places within our system configuration. 
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Step 6: 
Test each tool to validate the functionality of the tool with its previous documenta- 
tion. In most cases the previous documentation did not make much distinction 
between the long term designs and the state of the actual implementations of the 


tools. 


Step 7: 
Identify areas of functionality which would significantly improve the usefulness of 
each tool. 

Step 8: 
Correct bugs discovered during the sixth step, implement features of the tools which 
were described in the previous design but which had not actually been imple- 


mented; and implement features identified in step seven. 


Step 9: 
Identify test cases which were appropriate for the current state of the environment 


and test the tool from within CAPS. 


Step 10: 
Document the results of the ninth step and to document any new ideas which 


resulted from the integration testing and evaluation of the current tool. 


C. PORTABILITY AND SYSTEM DEPENDENCIES 


The primary goal of the CAPS designers is to focus on the design and feasibility of 


developing a rapid prototyping environment and not on the development of a production 
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system. An early decision was made to accept dependence upon the best locally avail- 


able resources. Portability of our particular environment is considered a secondary goal. 


Our implementation currently uses the local Sun system configuration and depends 
on features of the local installation such as the server and printer names on our Sun NFS. 
The use of these local resources enhances the development process by permitting more 
flexibility in the use of local resources shared by many other students and faculty at our 
research location. The use of system dependent name definitions have been localized to 
the front end of the user interface. This localization allows the system to be redefined 


with minimum effort. 


An early decision was also made to utilize existing tools for the development of our 
own tools and our environment. Part of the research involved with the development of 
our environment and its tools was to survey and evaluate existing tools which were 
potential candidates for use in developing our tools or as candidates to be integrated into 


CAPS to represent one of our tools. 
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IV. THE USER INTERFACE 


A. PREVIOUS DESIGN 


The previous design of an expert user interface [23] defines an interface which pro- 
vides sequence control with data protection. The user interface guides a user through the 
rapid prototyping process according to the following guidelines [23]: 


- "The interface must be able to interpret what the user is doing at 
any time and provide support”. 


- "The expert system must communicate with the users to find out what 
they want to do at any moment when the system cannot be sure of the 
user’s intentions". 

The following goals were defined in the design of the user interface: 

- Required input data should only be entered once. 

- Feedback should always be provided during data entry. 


- The user interface should be adaptable to accommodate both the 
novice and the experienced user. 


The major commands defined in the top level user’s manual were: 
- caps 


- construct 
- execute 


- modify 


B. PREVIOUS IMPLEMENTATION 


An implementation for the user interface had not been previously developed. Raum 


[23] described and implemented a link statement analyzer as part of the user interface. 
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The link statement analyzer translates the link statements generated by the graphic editor 


into textual PSDL constructs. 


The input to the link statement analyzer is a data component produced by the graphic 
editor and stored in the file graph.links. The data in this file are PSDL link statements 
which represent the graphic structure of a PSDL design. The form of a link statement 
without an optional maximum execution time is name.source->sink where namie is the 
name of the data, and source and sink are either the keyword EXTERNAL or names of 
operators. The form of a link statement with an MET is name.source:MET->sink. Fig- 
ure 4-1 (a) shows a PSDL design produced with the graphic editor. The corresponding 


link statements generated are depicted in Figure 4-1 (b). 


The link statement analyzer processes the link statements and generates two new data 
components. A file called psdl.ds is created which contains a list of all PSDL data 
streams in the graph. Additional files are created for each operator in the graph. These 
files are called NewNode.XX, where the XX represents arbitrarily assigned consecutive 
numbers. The NewNode.XX files are textual PSDL specification parts which contain all 
the information about an operator which was entered through the graphic editor. These 
files are intended to represent the prototype in the design database. This design does not 
account for multiple instances of prototypes, or describe how related components are 
linked together in the design database. Figure 4-2 (a) shows the data component psdl.ds 


and Figure 4-2 (b) shows the data components NewNode.01 and NewNode.02. 


Although the link statement analyzer was first designed as part of the user interface, 


we now consider it to be a component of the graphic editor. 
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Figure 4-1. PSDL Graph and Link Statements 
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Figure 4-2. Products Of The Link Statement Analyzer 


C. MODIFICATIONS TO THE DESIGN 


Our modifications and enhancements to the previous design addressed the following 
issues: 

- the responsibilities of the user interface 

- amethodology for user interaction 


- the menu functions 
- view consistency 
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1. User Interface Responsibilities 


We redefined the meaning of the user interface for implementation purposes. 
Raum ’s design of the user interface maintained the idea that the user interface was one of 
the three main components of CAPS. Raum described Boume Shell Scripts which only 
managed the activities of the components of the user interface, such as the graphic editor, 
syntax directed editor, browser, expert system and the debugger. As described in the pre- 
vious chapter we now view the user interface as the shell of the environment which 
interacts with the user and manages all of the tools within the CAPS environment and not 
just the tools which interact with the user. The effect of this modification changes the 


responsibilities of the user interface. 


The caps command was originally intended to be used to place the user into the 
user interface portion of CAPS. The original caps command was to allow an optional 
argument to assign a name to a new prototype. The caps command is now used to enter 
the CAPS environment. The specification of a prototype name is not appropriate at this 


level and the names of prototypes will be controlled from within the environment. 
2. Methodology For User Interaction 


We decided to design a simple menu driven interface for our initial integration. 
Since the functionality of the user interface had not yet been well defined, we wanted to 
provide a simple mechanism for integrating the previous work on the various tools. We 
chose text menus as our first mechanism for user interaction. We decided to utilize 
mnemonic lettering for option selections. Selections are made by typing the first lower 


case letter of an option at the prompt. The character selection mechanism only requires 
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that the user remember the activity that he wishes to be performed. This approach sup- 
ports type-ahead selections and system evolution [24]. Ultimately, we intend to imple- 


ment a graphic interface. 
3. Menu Functions 


We defined menus which guide the user through the process of rapid prototyping. 
The main menu contains the functions: 
- construct 
- execute 
- modify 
- quit 
The construct option places the designer in another menu which displays the 


choices of construction tools. Currently the choices are to use the graphic editor or the 


syntax directed editor. 


The execute option activates the execution support tools. These tools are the 
translator, the static scheduler and the dynamic scheduler. After these tools produce the 
data components which represent the executable prototype, the data components are 


automatically compiled, linked, and executed. 


The execution status messages were previously defined as: 


Translation Complete 

Static Scheduler Complete 
Dynamic Scheduler Complete 
Compilation Complete 
Linking Complete 

Execution Complete 


These messages were used to bridge the wait time the user experienced while these 


actions are performed. These messages were to be displayed after the action occurred. 


30 





We realized that a message which informs a user of the current activity rather than the 
previous cause of delay, is generally more satisfactory. The status message for linking 
was determined to be unnecessary. The execution support tools each produce data com- 
ponents which partially represent the executable prototype. All data components are 
compiled and linked during the compilation state. We defined two status messages 
which reflect the execution of the prototype. Since the execution of an embedded system 
implies a continuous system, we defined an additional status message which responds to 
a uSer input of turning off the system. The current status messages are: 

Translating ... 

Building Static Schedule ... 

Building Dynamic Schedule ... 

Compiling ... 


Executing ... 
Execution Complete 


The modify option had not yet been well defined in the previous documentation. 
We have defined the modify process to be equivalent to the construct process with one 
major difference. When the modify option is selected a window should be opened which 
contains the top-level names of all existing prototypes in the design database. The user 
should be able to select a prototype for modification by selecting an entry with the 
mouse. If the user selects a prototype with a .graph suffix, the graphic editor should be 
automatically activated by the user interface. If the user selects a prototype with a .text 


suffix, the syntax directed editor should be automatically activated by the user interface. 


The quit option was not defined in the previous documentation. The quit option 


should be used to permit the user to clean up versions of prototype designs which were 
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generated during the current session before exiting the environment. This process could 


occur as shown in Figure 4-3. 





Do you wish to save: 


prototypel.text? (y/n) 
prototypel.graph? (y/n) 
prototype2.text? (y/n) 
prototype2.graph? (y/n) 


a SKK 


Figure 4-3. Quit Process 





4. View Consistency 


A view is a representation for a particular abstraction. Multiple views may be 
associated with the same abstraction. View consistency defines a principle where multi- 
ple views of the same abstraction are always equivalent. This means that a change in one 
view must be reflected in all other views which represent the same abstraction. View 
consistency between the graphic and textual representations of prototype designs was an 


important issue of integration which stil requires further consideration. 


Since the construction of a prototype design is expected to be an iterative process, 
consistency issues are an immediate concem. Because CAPS supports the evolution of 
software systems which may be developed and maintained by a large number of develop- 
ers, we Should not constrain the view of a prototype to the preferences of one particular 
user. A view of a prototype may be required by multiple users in the development pro- 


cess, and may be required by many other users during evolution. 
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The view consistency problem is affected by the capabilities of the graphic editor 
and the syntax directed editor. This means that the problem is different dependent upon 
whether a prototype may be completely or partially described within each tool. If we 
constrain the capability of the graphic editor to describe only a simple data-flow diagram 
which represents the PSDL graph construct and not permit the capability to completely 
describe the prototype, then we define this as a partial graphic view. If the syntax 
directed editor does not permit the capability to describe textually the link statements of a 
PSDL graph construct, then we define this as a partial textual view. If a prototype may 
be described completely within the graphic editor or the syntax directed editor, then we 
define these views as a complete graphic view or a complete textual view. The method 
of interaction between the construction tools will be dependent upon the final capabilities 


of the tools. 


An initial view consistency exists for prototypes designed with the graphic editor. 
The graphic editor generates a textual representation which 1s used by other tools later in 
the rapid prototyping process. Our initial pipeline communication design will not ade- 
quately support view consistency for prototypes which were initially described as a tex- 


tual representation or for modified textual representations. 


The problem with view consistency for textual representations is that the two 
dimensional translation of logical objects into a graphic representation does not have a 
generally satisfactory solution. Even if both tools utilize a common data structure, the 
logical objects in the common data structure would still require a graphic translation for 


the layout used in the graphic editor. 
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One solution which supports view consistency is to define the graphic editor as 
the primary construction tool from which the prototype is completely described. The 
interaction with the graphic editor would produce a partial graphic view and interaction 
with the syntax directed editor would produce a partial textual view. The graphic editor 
would utilize the syntax directed editor as an underlying mechanism to provide for 
describing its textual attributes. The interaction between the editors must be defined so 
that objects which are defined graphically cannot be modified by the syntax directed edi- 
tor. This requires that the user have limitied access to the textual representation of a pro- 


totype within the syntax directed editor. 


C. IMPLEMENTATION 


The user interface was implemented in the C programming language [25]. This 
language was chosen due to the ease with which it interfaces with the unix shell. The use 
of the C programming language gave us the power and structure of a high level language 
and still provides very easy access to shell commands from within the program to 


manage the various CAPS tools. 


The simplicity of our menu design enables a user to traverse the system with an ease 
comparable to that provided by graphic interfaces. If an invalid selection is entered by 
the user, an error message is displayed, and the user may enter another selection. An 


sample of the menu design is provided with the main menu in Figure 4-4. 
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COMPUTER AIDED PROTOTYPING SYSTEM 


(c) onstruct 
(e) xecute 
(m) odify 

(q) uit 


Select Option: 


Figure 4-4. CAPS Main Menu 


Each valid selection from a menu clears the screen, then either places the user in a 
submenu if further choices are available or places the user within the environment of a 
particular tool. This occurs by creating a new unix process which executes the desired 
tool as a concurrent process with the user interface or any other currently active tools. 


The implementation of the user interface is contained in Appendix B. 
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V. THE GRAPHIC EDITOR 


A. PREVIOUS DESIGN 


The graphic editor [10] was designed to support efficient construction and 
modification of the graphical representation of PSDL prototypes. The graphic editor 
assumes that it is running on a Sun Workstation with a three button mouse. It uses both 
keyboard and mouse inputs. The control options of the graphic editor include load exist- 


ing prototype, Store current prototype, and quit the graphic editor. 


Graphic representations of PSDL prototypes can be created by selecting the follow- 
ing editing modes: 
- draw operator 
- draw input 
- draw output 


- draw data stream 
- draw self loop 


The graphic symbols which represent the corresponding language constructs are created 
by the following process: 
1. Position the mouse locator at the desired position in the drawing space. 
2. Press the left mouse button down. 
3. While holding the left mouse button down, move the mouse 
to a position which defines the size or length of the object. 


This rubber bands the type of object chosen in the editing mode. 


4. Release the left mouse button when the desired length or location 
is obtained. 
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The keyboard and the text input mode are used to define identifier names and maximum 
execution times (MET). All operators, inputs, outputs, data streams and self loops must 
have identifier names specified. Additionally all operators must additionally have METs 
specified. Objects are deleted by positioning the mouse on an object and pressing the 


right mouse button. Error messages are overlaid in the drawing space. 


The layout of the previous graphic editor is shown in Figure 5-1. 


MRC ee a 
Ouil | « 








DRAW DATA STREAM DRAW SELFLOOP DRAWINPUT DRAW OUTPUT] # 


Identifer Name : 


Max Excc Time : {Read MET 


* system control group # editing mode group + text input group 


Figure 5-1. Previous Graphic Editor 
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All graphic representations of designs are to be stored and managed by the design 


database. Thorstenson [10] states that: 


"If the graphical editor is going to be used to edit an existing diagram, 
the user interface function must retrieve the necessary reconstruction in- 
formation from the design database and store the information in a file 
named graph.pic prior to invoking the editor. The graphical editor then 
reads in this information and reconstructs the diagram." 


The graphic editor only allows objects to be related to other objects as defined by 
PSDL. Operators are represented by bubbles. Bubbles may not overlap. Data streams 
are represented by arrows where both the tail and head of the arrows are connected to 
operators. Inputs are represented by arrows whose tails must be positioned in unoccu- 
pied drawing space and heads must be connected to an operator. Outputs are represented 
by arrows whose tails are connected to an operator and heads are positioned in unoccu- 
pied drawing space. Self loops which represent state variables appear as arrows whose 
tails and heads are both connected to the same operator. PSDL operator decomposition 
also requires that all of the components of an operator are named. The graphic editor 
will not permit an object to be entered into the drawing space until after the identifier 
name has been entered and validated in the text input mode. PSDL operators also have a 
MET associated with them which must also be specified before they may be drawn in the 
drawing space. The identifiers must be syntactically correct Ada identifiers. The form of 


a syntactically correct identifier is shown in Figure 5-2. 
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identifier 
letter 
Metter or digit 


letter {[under¥Yine) Vetter or digit} 
upper _ case letter | lower case letter 
letter | digit 


Figure 5-2. PSDL Identifier 


The form of a syntactically correct MET is shown in Figure 5-3. User input which 
fails to meet the syntax requirements of PSDL is ignored, such as an input without an 


associated operator, or an output without an associated operator. 


MET 
digit string 
time_unit 


digit string {time_unit} 
digit | digit string 
fh? | 'm! | is! | ‘ms’ 


Figure 5-3. PSDL MET 


Previous documentation did not describe any direct interface between the graphic 
editor and the syntax directed editor, nor did it describe the decomposition of a prototype 


design from within the graphic editor. 


B. PREVIOUS IMPLEMENTATION 


The implementation of the graphic editor utilizes the suntools, sunwindows, pixrect 
and math libraries on a sun 3 system. The implementation of the graphic editor consists 


of programs written in C, Pascal and UNIX C Shell. 


39 


C. INTEGRATION 


The integration of the graphic editor into CAPS required that the component parts 
which comprise the graphic editor and the data components produced by the graphic edi- 
tor be identified and relocated into our system configuration. The dependencies between 
the graphic editor components and the data components were also identified. The user 
interface was modified to activate the graphic editor when the designer selected it from 


within the construction menu. 


The components which comprise the graphic editor reside in the directory: 


/caps/graphic_editor. These components are: 


editor.icon - icon for graphic_editor window 

ge - C shell script program 

graph - executable window based graphic editor 
graph.c - C source code for graph 

makid - executable utility to compile graph.c 
makid.c - C source code for makid 

nodes - graphic design link analyzer 

nodes.p - Pascal source code for nodes 


The products of the graphic editor which represent views of a prototype are placed in the 
directory: /caps/prototypes. 

The graphic editor is selected by the user interface (/caps/caps). The user interface calls 
the graphic editor by creating a new process, which is a copy of the current process, and 
then overlaying the new process with the script program, ge. This code segment is 


shown in Figure 5-4. 
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if (fork() == 0) { 
code = execl (SHELL, SHELL, "-f£", GRAPHIC EDITOR, 0) 
exit (code) 


SHELL represents /bin/csh 
GRAPHIC EDITOR represents /n/suns2/work/caps/graphic editor/ge 


Figure 5-4. Code Segment 


ge is dependent upon: 


/caps/graphic_editor/graph 
/caps/graphic_editor/nodes 


ge creates the following file: 
/caps/prototypes/psdl.imp 


graph.c is compiled by "“makid graph.c" 
which is equivalent to "cc graph.c -o graph -lm -lsuntool -lsunwindow -Ipixrect" 


graph is dependent upon: 
editor.icon 


graph creates the following files: 
/caps/prototypes/graph.links 
/caps/prototypes/graph.pic 


nodes.p is compiled by "pc nodes.p -o nodes" 


nodes is dependent upon: 
/caps/prototypes/graph. links 


nodes creates the following files: 


/caps/prototypes/psdl.ds 
/caps/prototypes/NewNode.XX’s 
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D. INTEGRATION TESTING 


The following inconsistencies, missing features or important enhancements were 


identified during the testing of the graphic editor. 


1) The frame title in the previous documentation was stated as Graphical Editor. The 


frame title in the implementation was dataflow diagram editor. 


2) There was no facility to print a hardcopy of a prototype design. The ability to print a 
hardcopy of the graphic representation of a prototype was also determined to be an 
important enhancement for documentation purposes. The use and capabilities of the 
graphic editor could be described in written documentation much more clearly with the 


ability to show the format of the graphic editor. 


3) The graphic editor utilized only a portion of the monitor. The default window size of 
the graphic editor was proportional to the monitor and used about 75 percent of the avail- 
able screen space. 

4) A segmentation violation occurred intermittently. On a UNIX system a segmentation 
violation indicates that a pointer has an assigned address outside of the user’s data space. 
5) Whenever an input, output or data-flow was erased from the drawing space, the last 
pixel on the tail of an input, output or data-flow remained visible. 

6) The functions of the mouse buttons were not visibly described within the screen 


image of the graphic editor. 


7) The graphic editor waming and error messages were displayed in the drawing space, 


permitting the possibility of overlaying the graph. 
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8) The graphic editor has separate store and quit buttons yet the user was not permitted 


to exit the graphic editor via the quit button unless the design had been stored first. 


9) The operator data components produced by the link statement analyzer were not com- 


plete specification constructs. 


10) The command line help facility was not effective once the graphic editor was 


integrated into the environment. 


11) The delete operation was unpredictable. This feature was not completely imple- 


mented in the previous implementation. 


12) Inputs, Outputs and Data-flows were not clipped. These symbols are drawn exactly 
as specified by the mouse inputs and not adjusted to the edges of the operators. The 
impact of this is that the construction of a nice looking prototype can become tedious. 


This problem becomes worse on workstations with smaller monitors. 


13) The graphic editor requires that the designer selects the tail position of an input, out- 
put, or data-flow before the designer selects the head position of the input, output, or 
data-flow. If the designer selects the end points of an input, output or data-flow in the 
head then tail order, the input, output or data-flow simply disappears without any expla- 
nation as to why the object was ignored. This is a cumbersome and unnecessary con- 


Straint on the user. 
14) The objects in the graphic editor cannot be resized. 
15) The objects in the graphic editor cannot be moved once positioned. 


16) Data flows cannot be inverted. 
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17) The keyboard inputs for the identifier names and maximum execution times are 
translated to literal text characters. Backspaces used while entering these fields appear to 


behave normally but show up as control characters in the output files. 
18) The names of objects in the graph are not required to be unique. 


19) Names and time constraints may not be modified once their associated object is 


placed in the drawing space. 


20) Units for time constraints in the PSDL language definition have a default value of 


milliseconds. The graphic editor does not recognize this feature of the language. 


21) The previous design assumed that only one single graphic view of a prototype would 


exist when the load existing button was activated. 


22) The mechanism for prototype decomposition was not described in the previous 


design. 


23) A complete prototype description cannot be entered within the graphic editor. 


E. MODIFICATIONS TO THE DESIGN AND THE IMPLEMENTATION 


The first ten items have been corrected in the design and the implementation. The 
eleventh item was partially corrected, the remaining items have been corrected in design 
only. 

1) We changed the frame title of the graphic_editor from dataflow diagram editor in the 
implementation to CAPS - GRAPHIC EDITOR in both the design and the 


implementation. 
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2) We added a print screen option to the graphic editor. This was implemented by creat- 
ing a new control option button in the system control group panel of the graphic editor 
for print design. The print design selection causes a screen dump to a file, which is then 
sent to a printer. This option performed well when the graphic user was displayed on a 
window device which was physically connected to a Sun server. The file did not survive 
transfer across the network, when the physical window device was connected to a disk- 
less workstation, due to the size of the transfer file. Since the functionality of the print 
design button is inoperative on diskless workstations, a further modification was made to 
determine the physical device that the user is on before displaying the print design but- 
ton. If the user is physically located on a diskless workstation then the button is not pro- 


vided. 


3) We resized the default size of the graphic editor to better utilize the monitor display. 


The graphic editor now utilizes 100 percent of the screen space. 


4) We initialized dynamic memory to NULL in graph.c to correct the segmentation vio- 
lation. This required systematic debugging to locate the source of the problem. The 
location of the segmentation violation was in nodes.p. However, we traced it to graph.c 


where memory was dynamically allocated but not initialized. 


5) The tail pixel on inputs, outputs and data-flows was not erased when the rest of the 
graphic symbol was erased. This occurred when inverting the pixels on the display from 
the last mouse position to the current mouse position for pixels between the tail and the 
head of the graphic symbol. This was accomplished with a built in sunview function. To 


correct this problem the drawing space is redrawn when a symbol is erased. Since the 
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tail pixel is deleted from memory when a symbol is erased, redrawing causes the tail 
pixel to disappear. 


6) A mouse interface panel was created. This panel explicitly denotes the functions of 
the left, middle and right mouse buttons. The mouse interface panel resides as the top 
panel of the graphic editor since the designer must know how to interface with the editor 
before he can make use of the tool. This reduces the size of the drawing space some- 
what, but contributes to the usefulness of the graphic editor significantly. In considera- 
tion for maintaining maximum area for the drawing space the editing mode panel was 
reduced in size to eliminate unnecessary wasted space. During the design of the mouse 
interface panel we also realized that the labels and buttons of the previous design were 
not consistent. We corrected this as well. A later modification might be to enable the 


expert user to delete this panel in favor of a larger drawing space. 


7) A message panel for editor error messages and wamings was designed into the 
graphic editor to avoid the possibility of overlaying the design with graphic editor mes- 


sages. This panel resides immediately above the drawing space. 


8) The capability to quit without saving a current session with the graphic editor was 
implemented. Previously the designer could not quit the graphic editor without storing 
the design, although two independent buttons are used for these functions. The previous 
implementation would display a warning message that the graph had not been saved, and 
would then ignore the request to quit. The designer could quit without storing by using 
the pull down menu of the graphic editor frame. This design feature essentially 


encouraged the designer to circumvent the tool. Since it is easily recognized that the 
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designer might like to quit without storing his current work, this option was integrated 
into the graphic editor. This was accomplished by using the sunview confirm feature 
when the quit button is selected and the graph has not been saved. If the designer selects 
quit without having saved the graph, then a waming message is displayed and a pop-up 
confirmation sequence occurs. If the designer does want to save the graph before quit- 
ting, then he may click the right mouse to cancel the quit request. If he did intend to quit 


without saving then he may click the left mouse to confirm his request. 


9) The operator data components produced by the link statement analyzer were corrected 
to append the PSDL keyword END to the NewNode product. In the PSDL grammar all 


SPECIFICATION keywords are bracketed with the keyword END. 


10) The previous design and implementation included a command line help facility. 
Since the graphic editor is an integrated tool within the CAPS environment, and is 
invoked from within the user interface and not from the command line, this facility was 


deleted. 


11) The delete function was evaluated and partially corrected. The first bug identified 
was the incorrect use of the C free function for dynamic memory. The free function was 
applied to memory which was automatically allocated rather than dynamically allocated. 
Kernighan and Ritchie state that "it is a ghastly error to free something not obtained by 
calling calloc or malloc" [26]. This was corrected by eliminating the free function calls 
within the file graph.c. The second bug related to the inconsistent behavior of the delete 
function. It appeared as if all objects which are represented by arrows in the graphic edi- 


tor such as inputs, outputs, data-flows and self loops should be able to be deleted by 
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pressing the right mouse button on the tail or the head of the object. But when the right 
niouse was pressed on the head of a self loop the associated operator and all of its inputs, 
outputs, data flows and self loops were deleted. Investigation revealed that when the 
right mouse was pressed, if the mouse was located on an input, output, data-flow or self 
loop the respective line would be deleted. If the right mouse was pressed and the graphic 
editor did not determine that the mouse was positioned on an arrow, then it checked to 
see if the right mouse was within an operator. When the right mouse was pressed on the 
head of a self loop, and if the head of the self loop was located within an operator, the 
graphic editor would never recognize that the mouse was positioned on a arrow so the 
delete operations for an operator would be activated. The implementation for drawing 
arrows in the drawing space uses variable names which correspond to points within a 
Cartesian coordinate system. The algorithm which creates the data structure which 
represents an arrow always uses (xl,y1!) as the tail and (x2,y2) as the head. The algo- 
rithm for checking if the right mouse is on a arrow, only checks if the mouse is posi- 
tioned on the head or the tail of an arrow. When a self loop is created (x1,y1) is the tail, 
but (x2,y2) is not actually the head. The actual Cartesian coordinates of the points for a 


self loop are shown in Figure 5-5. 
(x1, y2) (x2, y2) 
(x1, yl) (x2, yl) 
Figure 5-5. Self Loop Locations 
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The head of a self loop is actually the point (x2,y1). The values stored as the head of a 
self loop in the current implementation are (x2,y2). Currently a self loop may be deleted 
by selecting (xl,yl) or (x2,y2) with the middle mouse button. This causes the incon- 
sistencies noted during testing. Since the algorithm does not recognize (x2,y1) as the 
head of an arrow, if the arrow intersects an operator, then the operator and all related 
objects are deleted (including the self loop). We decided that limiting the recognition of 
an arrow to the end points was a poor design decision. Rather than correct the imple- 
mentation to store (x2,y1) as the head of the self loop, we chose to temporarily resolve 
this problem by redefining the mouse interface panel to state explicitly that deletion of 
self loops is performed only when the mouse is positioned on the tail of a self loop. The 
correct way to fix this problem is universal to all objects represented by arrows. The 
graphic editor should be able to recognize all points along a line. When any object in 
the drawing space is selected for deletion, the object should be highlighted in some 
manner. A verification mechanism should also be utilized to avoid inadvertent deletions. 
A pop-up window which requires that the designer verify the deletion should used when- 


ever a delete operation is requested. 


12) The input, output and data-flow symbols need to be clipped. The type of symbol is 
specified, before the location or end points of the symbols are specified. The syntactic 
correctness is checked using the symbol’s related operators. The location of the opera- 
tors is known to the graphic editor. The graphic editor should adjust the head of the input 
and data-flow symbols to the borders of their respective operators. The tails of the output 


and data-flow symbols should be adjusted to the borders of their respective operators. 
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This will greatly reduce the precision required of the designer to create a graphic 
representation of the prototype with a neat appearance. 

13) The tail then head constraint on the selection of input and output mouse selections 
should be removed. Since a draw input or draw output has been selected before the user 
specifies the end points, the graphic editor should be able to determine the appropriate 
head and tail position, and should pemnit the designer to select the end points in either 
order. 

14) The additional capability to resize objects should be implemented. Currently the 
designer must delete then redraw an object which he would like to resize. The current 
deletion of operators removes all related textual information and adjacent arrows, which 
further compounds this problem. Without a resizing capability, the designers might 
eventually lear to always draw their designs on a small scale to ensure that they do not 
nin out of drawing space. This type of compensation would encourage poor utilization of 
the drawing space and the tool. A resizing capability will enhance the friendliness and 
usefulness of the graphic editor significantly. The resizing of objects may be imple- 
mented by allowing the designer to select the border of an object by pressing down on 
the lett mouse button, dragging the mouse while the object rubber bands, and when the 
object obtains the desired size, releasing the left mouse button to effect the change in size 
of the object. 

1S) The unplementation of the additional capabuity to relocate objects in the drawing 
space ts required. The lack of the ability to relocate objects will have the same negative 


impact on a designer as the inability to resize objects. The designer may leam to over 


compensate thus reducing the effectiveness of the graphic editor. The relocation of 
objects may be implemented with the following process. The designer should select the 
border of an object to relocate by pressing down on the left mouse button. Then he 
should drag the mouse to move the object. When the object has the new desired location 


the designer may release the left mouse button to effect the change. 


16) The ability to invert data-flows would be a nice enhancement. This should be imple- 
mented by copying the existing end points, rewriting them in reverse order into the per- 


manent data structure, and then redrawing the display. 


17) The correct translation of keyboard back space input is essential since the output of 
the graphic editor is used as input for other tools in the environment. The file nodes.p 
must be modified to check for the back space control character, and then adjust the char- 


acters in the text buffer appropriately. 


18) The implementation of name analysis is an essential feature. A data structure should 
be created which contains the names assigned to data flows and operators. Before new 
names are accepted by the graphic editor, the names should be compared with existing 
names. The graphic editor should analyze the object being named and ensure that 
conflicts or multiple declarations are not defined. If the new name violates these condi- 
tions, then a message should be displayed in the message panel and the designer should 


redefine the name. 


19) The modification of names and time constraints independently of their associated 
operators requires that the graphic editor recognize the boundary of the names and time 


constraints associated with an operator when selected with the mouse. Functions should 
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be provided in the file graph.c which control the modification of these objects whenever 
they are selected. 


20) Currently a time constraint is required by the graphic editor for all operators. This 
requirement should be removed. If the designer does not enter a time constraint then a 
default value of zero should be assigned. Currently, units are required for all time con- 
straints. Since the PSDL language uses milliseconds as a default value, the function 
within the graphic editor which enforces the entry of units, should be modified to allow 
the designer to omit this information. If the designer does not explicitly enter the units of 


time then the default value should be assigned. 


21) The previous design decision to have the user interface retrieve the necessary recon- 
struction information from the design database and store the information into a file called 
graph.pic, and to then have the designer select load existing after the graphic editor 
becomes available, separates the retrieval function into two different interfaces. This 
function should be entirely controlled by either the user interface or the graphic editor. 
Our design modification is to place this function entirely within the graphic editor. This 


should occur with the following sequence of operations. 
a. The designer selects the /oad existing button. 


b. A pop-up listing is displayed in the drawing area which contains the names of the 
existing designs. These designs should be ordered such that the most recently developed 
designs occur in the listing before the other designs. This ordering assumes that designs 
to be modified are more likely to be designs which were incompletely reconstructed or 


pertain to the most recent development project. 
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c. The designer should select a design by typing the name with the keyboard into a small 
window space or by pointing at a name with the mouse and pressing a mouse button to 


make the selection. 


d. The graphic editor makes a copy of the design file with a suffix reserved for backup 


files. 
e. The design is loaded into the graphic editor. 


f. If the designer selects store with this design, then he is queried as to his desires for the 
backup copy. He should be able to rename or remove the old copy. Eventually the 
design database should perform version control and manage all of the versions of a 
prototype. 

g. If the designer selects quit without having stored the current version of the design, 
then the edited version is removed and the name of the backup copy is restored to its ori- 


ginal name. 


Consistency of design indicates that the graphic editor should control the naming of all 
graphic designs. Naming should occur when the store button is selected. Until the 
design database is implemented, the directory /caps/prototypes/ should be used to contain 


the prototype designs. 


22) The decomposition process of a PSDL prototype design was not previously 
described. The existing data structures currently used in the graphic editor should be 
modified to add another dimension. This dimension would generate a linked list of 
operators to their decompositions. Three new buttons search, decompose and compose 


should be added to the system control group panel. The search button interacts with the 
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Database Management System. The implementation of this function should provide the 
user with the capability to retrieve both prototype designs and reusable software com- 
ponents. This button has been added to the graphic editor layout but its functionality has 
not yet been implemented. The details of these operations are further defined in a later 
chapter. When the decompose button 1s activated, the user selects an operator in the 
current design, a link from the operator in the current data structure is created, and the 
drawing space is cleared. The user may now construct the decomposition of the selected 
operator. Information related to an operator must be consistent with the decomposition of 
that operator. For example, if an operator has a defined input, then when the operator is 
decomposed that same input must appear as an EXTERNAL input in the decomposition 
of the operator. If the designer has defined adjacent inputs, outputs, data streams, time 
constraints or any other related information prior to selecting an operator for decomposi- 
tion, this information should be visible to the designer when constructing the decomposi- 
tion. The graphic editor must ensure that the information related to an operator is 
consistent in both the decomposition and composition of the operator. When the com- 
pose button is activated the drawing space is cleared and the design which contains the 
parent operator is displayed. The decompose and the compose buttons have been added 


to the graphic editor, but their functionalities have not yet been implemented. 


23) We believe that a user should be able to describe a PSDL design completely from 
within the graphic editor. Better utilization of sunview capabilities within the graphic 
editor and enhancements to the current data structures used within the graphic editor sup- 
port this modification. The use of pop-up menus and the use of multiple windows can 


provide an interface which avoids clutter and information overload. The current set of 
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graphic symbols remains sufficient. Optional PSDL constructs which relate to an opera- 
tor and are not currently supported by the graphic editor can be displayed within a pop- 
up menu. Selections made within a pop-up menu can generate dialogue boxes where the 
user describes the optional constructs. The dialogue boxes should be customized to sup- 
port effectively each optional construct. A few examples of these constructs include con- 
trol constraints, informal descriptions, and formal descriptions. Mechanisms used within 
these dialogue boxes can be question and answer, mini syntax directed editors, or simple 
text editors. This information represents an annotation view [27] of the operator. It will 
not be visually persistent but will be attached to the operator. The existing data struc- 


tures can be expanded to manage these constructs. 


The layout of the graphic editor as it is currently implemented, with a simple proto- 
type design, is shown in Figure 5-6. The functional components which comprise the 


graphic editor are contained in Appendices C through F. 
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Figure 5-6 





VI. THE SYNTAX DIRECTED EDITOR 


Language-based editors or syntax directed editors are editors which are tailored to a 
specific language. These editors use the grammar, structure and static semantics of a 
language to assist a user in writing correct programs. These editors generally enforce 
syntactically correct programs by providing program segment templates which contain 
legal alternatives for the specific language and prohibit legal constructs. They may also 
combine plain text editing with incremental parsing techniques to ensure that only syn- 


tactically correct program fragments are entered. 


A. LANGUAGE-BASED EDITOR GENERATORS 


Porter [11] performed a comparison of two predominant editor generators currently 
in use for developing language based editors. These tools were the Cornell Synthesizer 
Generator and the GANDALF ALOE Generator. Porter stated that the Cornell Syn- 
thesizer Generator [28,29] was the more appropriate tool for our purposes. The Gandalf 
tool provides an environment which permits team development of system software. It 
exceeds the scope of the Cornell Synthesizer Generator by providing both programming 
and system development environments. The desired PSDL editor is designed as a tool 
within the CAPS environment. CAPS provides its own system development capabilities. 
The development of a PSDL editor using the GANDALF tool would underutilize the 


GANDALF tool. 
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Porter established the feasibility and recommended the use of the Cornell Syn- 
thesizer Generator for the development of a PSDL editor for CAPS. We decided to fol- 
low Porter’s recommendation and did not conduct any further evaluation of editor 


generators. 


B. THE CORNELL SYNTHESIZER GENERATOR 


The Synthesizer Generator creates a language-specific editor from an editor 
specification which describes the language. The editor specification defines the abstract 
syntax, context-sensitive relationships, display format, concrete input syntax, and 
transformation rules for the editor. These specifications are written by the editor-designer 


using the Synthesizer Specification Language (SSL). 


The Comell Synthesizer Generator is written in C and runs under UNIX. The central 
components of an editor created from the Cornell Synthesizer Generator are the editing 


kernel and the generator proper. 


The editing kemel consists of four subcomponents which are common to all gen- 
erated editors. These subcomponents are an attributed-tree module, the SSL-expression 
interpreter, the editor module, and the display module. The attributed-tree module con- 
tains a set of operations for manipulating attributed trees. An example is the incremental 
algorithm for updating a tree’s attribute values after it has been modified. The SSL- 
expression interpreter is invoked by the attributed-tree module. This occurs when a new 
value of an attribute instance is to be computed and when a transformation has been 


applied to an attributed tree. The editor module provides the capabilities for 
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manipulating objects within an editor. These objects are contained in a collection of 
buffers. The editor module provides the system commands such as those for structural 
editing and textual editing. The display module provides the support for video-display 


terminals, bit-mapped workstations and mice. 


The generator proper generates editors from editor specifications. It consists of a 
shell program and the SSL translator. The shell program, sgen, coordinates the activities 
of the SSL translator with the UNIX utilities, such as lex, yacc and cc, which are 
employed during the process of creating an editor. The SSL translator processes the SSL 
source which represents the editor specifications. Four unique subcomponents are created 
for any generated editor. The subcomponents are the editor’s grammar tables, scanner, 
parser, and sequences of byte-codes which are the internal representation of SSL 


expressions. 


The SSL reserved words which may not be used by an editor designer for any other 


purpose are shown in Figure 6-1. 


and as default demand end 
exported ext_computers false forail foreign 
in inh inherited left list 
let local nil nil_ attr nonassoc 
on optional parse prec readonly 
repeated right root sparse store 
style syn synthesized transform true 
typedef unparse view with 

Figure 6-1. SSL Reserved Words 
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C. PREVIOUS DESIGN AND IMPLEMENTATION 


Porter generated some partial specifications for a PSDL editor, but the specifications 
were completely untested. After reviewing his work, we were unable to perform any 
editing with those specifications. We chose to define our own approach to development 


and to disregard the previous implementation. 


D. DEVELOPMENT OF THE PSDL EDITOR 


The modular development of an editor using the Cornell Synthesizer Generator con- 
sists of editor specifications which may be divided into six major components: 

- abstract syntax declarations 

- unparsing declarations 

- lexical declarations 

- concrete input syntax declarations 

- attribute declarations and equations 

- templates and transformations 
Modular construction permits the abstraction of the requirements of each component, 
enhances comprehensibility and incorporates effective extensibility for an editor. Good 
engineering practice was also employed by first defining a small subset of the PSDL 
language for the initial editor, while familiarizing ourselves with the specifics of the pro- 
cess for generating an editor. The purpose and implementation details for the construc- 
tion of each module is described using the initial subset of the PSDL grammar shown in 


Figure 6-2. Some of the PSDL nonterminals have been eliminated or are treated as ter- 


minals here in our subset. The complete PSDL grammar is contained in Appendix A. 
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psdl 

= (component } 
component 

= data type | operator 
data type 

= "type" id type_spec 
operator 

= "operator" id operator spec 
type _ spec 

= "specification" [type decl] "end" 
operator spec 

= "specification" {interface} "end" 


interface 

= attribute [reqmts trace] 
attribute 

= input | output 
input 

= "input" type decl 
output 


= "output" type decl 
reqmts trace 
= "by requirements" id list 





type decl 
=idgbist *":" id 
id list 
= id {"," id} 
id 
: = letter {alphanumeric} 
alphanumeric 
= letter | digit 
letter 
= "a..z" | "ALLZ™ YO 8 
digit 
=f %()....9" 


Figure 6-2. Original Subset Of PSDL Grammar 


The descriptions of the SSL modules embodies lessons learned during the generation 
of the editor that may be applied to the generation of any editor. We decided to make the 


initial editor for use on a video terminal rather than a workstation due to the availability 


of local resources. The final version of the editor within CAPS is expected to utilize 


graphics with a mouse on a Sun Workstation. 


Before writing any SSL specifications we recommend that the editor designer define 
an intermediate grammar. There may exist several conditions in the BNF dialect of the 
grammar which, if implemented literally, will probably produce an editor which is 
cumbersome to the user. The intermediate grammar will not change the meaning of the 
original grammar but will provide a more natural transition between the BNF grammar 


and the SSL declarations. 


Nonterminals that carry no specific semantic meaning should be eluminated. These 
nonterminals may exist in the BNF dialect of the grammar to enhance readability and 
understandability. When used in the abstract syntax they produce unnecessary editing 
steps and depth in the derivation trees. An example of this in our initial PSDL grammar 
is the production for component which resolves to a data type or an operator. We 
redefined component in our intermediate grammar to be a “type” id type spec or a 


"operator " id operator_spec. 


BNF dialects and SSL differ in the way that optional occurrences of nonterminals are 
treated. A BNF dialect uses a mechanism to state that an instance of a nonterminal is 
optional. SSL uses a property declaration for the nonterminal to state that it is optional. 
Thus all occurrences of that nonterminal are optional. We recommend that the editor 
designer identify nonterminals in the BNF dialect of the grammar which have both 
required and optional occurrences. A convention for creating new nonterminals in the 


intermediate grammar to differentiate between optional and required instances of the 
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nonterminals should be established. The new optional nonterminals carry the same 
semantic meanings as the original nonterminals. We created new nonterminals for 
optional instances and used a convention of prefixing optional_ to the name of the new 
nonterminal for optional occurrences. An example of this issue occurs in our original 
PSDL subset with the type decl production. We created a new _ nonterminal 
optional type _decl in our intermediate grammar. We also decided to maintain an 
expressive regularity by renaming all nonterminals which only had optional occurrences 


in the original grammar with the same optional_ prefix. 


BNF dialects and SSL also differ in the way that optional instances of sequences of 
terminals and nonterminals occur. In SSL a property declaration is used to specify that 
all occurrences of a nonterminal are lists, or optional lists. Lists in SSL are treated as 
binary trees. An SSL list must have exactly two operators. One operator is a nullary 
operator constructing an empty list and the other is a right recursive binary operator 
adding a new list element to a given list. A list in SSL must contain at least one element. 
A production list = list_item {list_item} would be reflected as a list in SSL. Optional lists 
permit an instance of the list which is empty. A production such as list = {list_item} 
would be reflected as an optional list in SSL. We recommend that the editor designer 
identify whether sets in the original grammar are lists or optional lists. We renamed the 
optional list nonterminals with the prefix optional_list_. In our original grammar inter- 
face is an optional list and was renamed to optional list interface in our intermediate 
grammar. In our original grammar id list is an list. Our intermediate grammar for the 


PSDL subset is shown in Figure 6-3. 
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psdl 

= list component 
list component 

= "type" id type spec | "operator" id operator spec 
type spec 

= "specification" optional_type _decl "end" 
operator spec 

= "specification" optional list interface "end" 
optional list_interface 

= attribute optional reqmts_ trace 


attribute 

= input | output 
input 

=@2input” type deci 
output 


= "output" type decl 
optional reqmts trace 

= "by requirements" id list 
type decl 

= id list. "7-10 
optional type decl 

= ad list". ad 
id list 

= id {"," id} 


id 

= letter {alphanumeric} 
alphanumeric 

= letter | digit 
letter 

se CA. ge Pig 
digit 

a A Be | 


Figure 6-3. Intermediate PSDL Subset 


1. Abstract Syntax Declarations 


The abstract syntax is the core of the editor specification. It is defined as a set of 
grammar rules. An object in the resultant editor is represented by a derivation tree which 


is constructed based on the grammar. 
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The abstract syntax declarations may easily be defined from the intermediate 
grammar. The literals of the grammar are not considered at this stage as they do not 
represent parts of a derivation tree. The abstract syntax for the PSDL subset is shown in 


Figure 6-4. 


Nonterminals with special properties such as optional, list or optional list are 
denoted by using the appropriate property declarations in the abstract syntax. Optional 


nonterminals must contain a nullary operator in addition to any other desired operators. 


The abstract syntax declarations are a collection of productions. In SSL produc- 
tions have the form x0 : op(xl x2 ... xk), where op is an operator name and each xi is a 
nonterminal of the grammar. The nonterminal is also referred to as a phylum. The phy- 
lum associated with a given nonterminal is the set of derivation trees that can be derived 
from it by using operators. These derivation trees are referred to as terms. The operators 


identify the production instances in a derivation tree. 


The SSL grammar rule acts like a context-free production x0 -> x1 x2... xk. All 
operator names must be unique. The operator of a production distinguishes it from the 
other alternatives provided by the left hand side phylum. One phylum in the abstract 
syntax declarations must be distinguished as the root phylum. All editable objects in the 


editor are terms of the root phylum. 


Phyla contain a completing term and a placeholder term. The same term may be 
both a completing term and a placeholder term. The first operator declared for each phy- 
lum is the completing operator. The completing operators construct default representa- 


tions for the phylum called the completing term. An instance of the appropriate 


65 


root psdl_components; 
list psdl_ components; 
psdl_ components 
Psd1Nil () 
| PsdlPair(component psdl_ components) ; 
component 
NoComponent () 
| Data(id type spec) 
| Op(id operator spec); 
operator spec 
OpSpec (optional_interface) ; 
type_spec 
: TypeSpec(optional type declaration) ; 
optional list optional _ interface; 
optional interface 
InterFaceNil () 


| InterFaceList (attribute optional interface) ; 


attribute 
EmptyAttr () 
| Input (input optional requirements) 
| Output (output optional requirements) ; 
optional optional requirements; 
optional requirements 
: ReqmtsTraceNone () 
| ReqmtsPrompt () 
| Reqmt sTrace (id_ list); 
input 
: InputTypeDecl (type _decl); 
output 
: OutputTypeDecl (type decl); 
type deci 
TypeDecl (id_list type_name) ; 
optional optional _ type declaration; 
optional type declaration 
Opt TypeDecl1Nil () 
| OptTypeDecl(id list type_name) ; 
type _ name 
TypeName (id) ; 
list adalast, 
id list 
>: IdNil() 
| TaPaie(id ids list); 
id 
: IdNull() 
| Id(IDENTIFIER) ; 


Figure 6-4. Abstract Syntax 


66 


= > 
rl eee 


ee ee 


ae 


SPR 








completing term resides at each unexpanded occurrence of a phylum in a derivation tree. 
The completing term of a list phylum differs in that the completing term is the singleton 
list constructed by applying the binary operator to the completing term of its left argu- 
ment phylum and to the list’s nullary operator. Placeholder terms identify locations 
where subterms may be inserted. The relationship of completing terms and placeholder 
terms varies dependent upon the property declarations for a phylum. For ordinary phyla 
and list phyla the same term is both the completing term and the placeholder term. For 
optional phyla the completing term is constructed from its first nullary operator. The 
placeholder term is constructed from the first operator which is not used to construct the 
completing term. For optional list phyla the completing term is constructed from the nul- 
lary operator, and the placeholder term is the singleton list constructed by applying the 
list’s binary operator to the completing term of the list’s left child and to the list’s nullary 


term. 
2. Unparsing Rules 


The next step in constructing an editor is to define the display representation. The 
display representation is described by a collection of unparsing rules. The unparsing 
rules define the behavior of the editor with respect to the abstract syntax. This module 
contains specifications for the display format and for denoting which nodes in the 


abstract syntax tree are selectable and which productions of an object are editable. 


The SSL form for unparsing rules is phylum : operator [unparsing syntax] where 
phylum and operator correspond on a one to one basis with the abstract syntax. The 


unparsing syntax includes a selection symbol which corresponds to the left hand side 
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phylum and a selection symbol for each node on the right hand side in the order in which 


the nodes occur in the abstract syntax. 


There may be locations in the derivation tree which need not be visible to the user 
of our editor. The selection symbol which denotes a node as a resting place in the 
derivation tree is a @. We denote nodes that we do not wish to be selectable, which 
means they are not resting places, by the ~ selection symbol. The selection symbol for 
the left-hand-side-phylum is separated from the right-hand-side-nodes by a : if we do not 
wish an object to be editable, or by a ::= if we do intend for the object to be editable. A 
node in the tree is an instance of two phylum occurrences. It occurs in the right-hand- 
side and in the left-hand-side. If either occurrence is represented with a @ symbol then 
the node represented the phylum will be designated as selectable otherwise it is not 
selectable. This characteristic necessitates the development of another convention. The 
editor designer should choose a convention for the insertion of resting places, either in 
place for the left-hand-side phylum or the right-hand-side phylum. We chose the left- 
hand-side phylum as our convention since the resting places were more easily recognized 
and fewer @ symbols were required in the unparsing rules. The trade-off with this 
choice is that if the editor-designer desires that a phylum be a selectable in one subtree 
and not selectable in another subtree then the unparsing rules must be modified to 
describe the right-hand-side occurrence as a resting place and the left-hand-side as not a 


resting place. This occurs infrequently in our PSDL language. 


The syntactic sugar of the language is interspersed within the unparsing syntax in 


the form of tokens. These tokens are enclosed within double quotes. Display 
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formatting such as newlines, tabs and back tabs may also be included within double 


quotes. The SSL display formatting commands are shown in Figure 6-S. 


Formatting 
Command 


Jot 

%b 
%n 

%1 

%1 
%oT 
%M(c) 
%o 

Joc 

Jo { 

%) 

Jo 

%| 
%S(style-name 
%S) 
%%o 


Meaning 


move the left margin one indentation unit to the right 
move the left margin one indentation unit to the left 
newline, return to the current left margin 

return to the current left margin and overprint 

move to column one of the same line and overprint 
move right to the next tab stop 

move right to column c, where c is a positive integer 
optional newline, retum to the current left margin 
same as %o, but either all or no %c in a group are taken 
beginning of an unparsing group 

end of an unparsing group 

same as %t% { 

same as %)}%b 

enter the named style 

revert to the previous style 

display a % 


Figure 6-5. SSL Display Formatting Commands 


Another convention should be established with regard to the placement of tabs 


and newlines. The consideration is whether to place the newlines in the front of the 


unparsing rules or at the end of the unparsing rules, and the level at which to place the 


tabs and the back tabs. The effect of the formatting commands for tabs and back tabs are 


realized upon the next occurrence of a newline. We chose to place the newlines at the 


front of the unparsing rules, and tabs and back tabs in the parent rules. The unparsing 


rules for our PSDL subset are shown in Figure 6-6. 
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psdl_ components 
Psd1Nil 
| PsdlPair 
component 
NoComponent 
| Op 
{| Data 
id 
IdNull 
{| Id 
operator spec 
OpSpec 
type spec 
TypesSpec 
optional _ interface 
InterFaceNil 
{ InterFaceList 
optional requirements 
Reqmt sTraceNone 
{| RegqmtsPrompt 
{| RegqmtsTrace 
attribute 
EmptyAttr 
f Input 
} Output 
input 
; InputTypeDecl 
output 
OutputTypeDecl 
type decl 
TypeDecl 


(@: 
[@: 
(os 
ie 
[2 
[@: 
[@: 


[= 


optional type declaration 


OptTypeDeclNil 
} OptTypeDecl 
type _name 
TypeName 
re Ti se 
IdNil 
{ IdPair 


[@: 
[@: 


Louse 


[@ 


[@: 


J 
lak 2 8 || laa 


"%n[component]"] 
"SnNOPERATOR ""7] 
"EnNTYPE “> [oe 


:="<identifier>"] 


eee 


:"SnSPECIFICATIONSt"*"%b%nNEND"] ; 


>"SnSPECIFICATIONSt"“"S$b%nEND"] ; 


>] 
>" (]@) ; 


>] 

>"&n{requirements}"] 

>"$nBY REQUIREMENTS$tén"""$b"j] ; 
>"Sn{interface}"] 

"Sn INPUT" "St" "EH" ] 
s"SnOUTEPUT {St “Sb") ; 

sBtttn" “Sb")] 3 


S"StSn"-"Sb"] ; 


ag ° eat ry 
e 4 


"%Sn{optional type declaration}"] 
WEenwsn ae | bd 


ae. 


:=] 


=", 


wpey 


Figure 6-6. Unparsing Rules 
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3. Lexeme Declarations 


The next step in the development of an editor is to define the lexical rules. The 
form of a lexeme declaration is phylum-name : lexeme-name < regular-expression >; 
This declaration states that all strings generated by the given regular expression are in 
phylum-name. The regular expression is separated from the closing angle bracket by at 
least one blank character. The regular expression may contain embedded blank charac- 
ters by explicitly escaping the blank with a back slash. The lexeme-name will be used in 
the concrete input definitions. The regular expressions permitted in the SSL lexeme 
declarations are generally the same regular expressions which are accepted by the UNIX 
lexical analyzer generator lex. Figure 6-7 contains guidance for acceptable regular 


expressions. 


Expression Meaning 


Cc the character c 

"clc2c3" the string clc2c3 

[clc2c3] the character cl,c2 or c3 

[cl-c2] any of the characters from cl through c2 
[“clc2c3] any character but cl,c2 and c3 

“e an e at the beginning of a line 

e$ an e at the end of a line 

a an optional e 

e* 0 or more instances of e 

e+ 1 or more instances of e 

ele2 an el followed by an e2 

elle2 an el or an e2 

(e) ane 

el/e2 an el but only if followed by an e2 
e{ni,n2} nl through n2 occurrences of e 


Figure 6-7. Regular Expressions 
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Lexeme declarations form an ordered list. During lexical analysis in an editor, 
this order influences the recognition process. When more than one regular expression 
matches a string, the longest match is selected. If several rules match with the same 
number of characters, then the first declaration which matched in the specification is 


selected. The lexeme declarations for our PSDL subset are shown in Figure 6-8. 


IDENTIFIER: IdentLex< [a-zA-Z] [a~zA-Z_0-9]* >; 


Figure 6-8. Lexeme Declarations 


4. Attribute Declarations 


The next step in the development of an editor is to define the attribute declara- 
tions. The attribute declarations define the association between the abstract syntax and 
the concrete input syntax. SSL attribute declarations associate an attribute with the name 
of a phylum. They also describe the type and the source of the attribute as either syn- 
thesized or inherited. The form of an SSL attribute declaration is phylum {source attri- 
bute type;},; This file also contains entry declarations which establish the correspondence 
between the selections in the abstract-syntax tree which are to be edited and the entry 
points within the input syntax. The form of an SSL entry declaration is p “P.t;. This 
example indicates that when a selected component of the program is a member of phy- 
lum p, input is to be parsed to determine if it is a member of P. If it is, then attribute f¢ 
should be inserted in the abstract-syntax tree, and should replace the current selection. 
The attribute declarations and their entry declarations for our PSDL subset are shown in 


Figure 6-9. 
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Ident {synthesized id t;}; 


fa list {synthesized id list t;}; 
id BelTAent. t ; 
id_ list epidvlist .t; 


Figure 6-9. Attribute Declarations 


5. Concrete Input Syntax 


The concrete input syntax of a language to be used for text editing is defined in 
terms of a concrete input grammar. It comprises the rules which specify the set of syn- 
tactically well-formed strings, the structure of parse trees, and attribute equations that 


specify the translation of the parse trees into terms of the abstract syntax. 


The attribute equations specify how values of synthesized attributes of the left- 
hand side nonterminals are computed in terms of their inherited attributes and 
synthesized attributes associated with nonterminals on the right-hand side. They also 
determine how inherited attributes of right-hand side nonterminals are constructed from 
inherited attributes of the left-hand side nonterminals and from synthesized attributes of 


left siblings. 


The minimum syntax required for an editor must provide for all language con- 
structs which are entered as text via the keyboard. Ultimately, the concrete input syntax 
should recognize the entire language to permit the user to read existing objects into a text 
file and then edit those objects. The concrete input syntax for our PSDL subset is shown 


in Figure 6-10. 
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Ident >= (IDENTIFIER) 
{Ident.t = Id (IDENTIFIER) ;}; 


Id rs e ::= (Ident) 
{Id 12st ,eo= a(tdent.c.  tdnNrije 
1 {identy 77 tdmixse) 
{Id list$l1.t = (Ident .t::iTd Wists? +), ), 


Figure 6-10. Concrete Input Syntax 


The left-hand side phyla name are separated from the right-hand side symbols 
with a ::= symbol. Single characters may be enclosed in single quotes on the right- 
hand side of the parsing declarations. Different occurrences of the same nonterminal are 
distinguished by appending a number, such as $1 and $2, which reflects their 
occurrence in the rule. The second rule in our syntax specifies that a list of identifiers is 
separated by a comma in the concrete syntax and that the lexeme values parsed are con- 
catenated to a list (using the predefined concatenation operator ::) whose value is 


stored in the synthesized attribute t of the nonterminal Id list. 


6. Templates and Transformations 


The next step is to define the templates and transformations. Transformations 
may define templates which are inserted whenever the selection is a placeholder or may 
compute a replacement value dependent upon the former value of the selection. We only 
defined template transformations for our first editor. These declarations specify the res- 


tructuring of objects when a current selection matches a given pattern. The general form 
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of a transformation declaration is transform x0 on transformation-name <x0> 
operator(<xI>,...,.<xn>),; , where transform and on are SSL reserved words, operator is 
an operator and x0 through xn are productions in the abstract syntax. The template 


transfonnations for our PSDL subset are shown in Figure 6-11. 





transform component 
on "type" 
<component> 
Data (<id>,<type spec>), 
on “operator" 
<component> 
Op (<id>,<operator_ spec>) ; 


transform attribute 
on "input" 
<attribute> 
Input (<input>,<optional_ requirements>), 
on *®output" 
<attribute> 
Output (<output>,<optional requirements>) ; 


transform optional requirements 
on “enter requirements" 
<optional requirement s> 
Reqmt sTrace (<id_list>) ; 
transform optional type declaration 
on “enter declaration" 


<optional type declaration> 
Opt TypeDec] (<id_list>,<type_ name>) ; 


Figure 6-11. Template Transformations 


E. DESIGN ISSUES OF THE COMPLETE PSDL EDITOR 


The PSDL Syntax Directed Editor described here and used in CAPS is a very 


simplistic editor with regard to the level of sophistication capable in an editor generated 
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from the Cornell Synthesizer. The simplistic design of our PSDL editor was intentional. 
We have purposely turned off features which may normally be included in an editor gen- 
erated from the Cornell Synthesizer Generator. We have purposely documented only a 
very small subset of the available editor commands. The subset of editor commands pro- 
vided in our on-line documentation is sufficient to use the PSDL editor as we intended. 
In an environment which contains multiple tools which interact with the user, we believe 
that the interfaces must be kept simple and should be as consistent amongst the different 
tools as possible. We felt that the trade-off in the complexity of the editor’s user inter- 
face with the additional capabilities provided by the Cornell Synthesizer Generator was 


not warranted for our application. 


Our editor is consistent with the principle that a user interface should always provide 
feedback for any user input. The display always changes in appearance any time the user 


enters an editor command or any other keyboard input. 


We have updated the PSDL grammar during the design and implementation of the 
PSDL editor. There were four changes in the grammar which were not simple factoriza- 
tions but that actually changed the meaning of the language. The first change simply 
made the grammar more regular. PSDL primary objects such as operators and data types 
have two parts: a specification part and an implementation part. The specification con- 
struct begins with SPECIFICATION and ends with END. The implementation part 
may consist of a psdl implementation or an ada implementation. The psdl implementa- 
tion construct begins with IMPLEMENTATION and ends with END. The ada imple- 
mentation construct began with IMPLEMENTATION ADA and contained an Ada pro- 


gram. An ada implementation did not require an END to bracket the construct. We 
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decided to change the grammar to require that an ada implementation end with an END 


to increase the regularity and syntactic consistency of the language. 


The second, third and fourth changes to the grammar involved a similar issue. The 
rules for data_flow_diagram, control_constraints and constraint permitted that the smal- 
lest correct use of the rules resulted in unsatisfactory conditions. The last three changes 
to the rules resulted in required subsets of the original grammar. The rules which relate 


to data_flow_diagram and control_constraints are shown in Figure 6-12. 





psdl implementation 
= "implementation" data flow diagram [streams] [timers] 
[control constraints] [informal desc] "end" 
data flow diagram 
= "graph" {link} 
control_constraints 
= "control constraints" {constraint } 


Figure 6-12. Original PSDL Rules 


The smallest correct psdl implementation which resulted from these rules is shown in 


Figure 6-13. 


IMPLEMENTATION 
GRAPH 
END 


Figure 6-13. Smallest PSDL Implementation According To Previous Grammar 


TI 


This yields an empty implementation. We decided that an empty implementation 
should not be permitted. The grammar was changed to require that a psdl implementa- 
tion contain at least one link statement. The change in the grammar is shown with its 


corresponding smallest construct is shown in Figure 6-14. 





data flow diagram 
= "graph" link {link} 


IMPLEMENTATION 

GRAPH 

id @." id 0" 3" se ime tea ac 
END 


Figure 6-14. Updated Psdl Implementation Rule And Its Smallest Construct 


The control constraints construct is optional in the psdl implementation rule. Previ- 


ously when selected, it could consist of keywords only, as shown in Figure 6-15. 


IMPLEMENTATION 
GRAPH 
id. “." ad [":* time | eee 
CONTROL CONSTRAINTS 
END 


Figure 6-15. Smallest Control Constraint According To Previous Grammar 
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We changed the PSDL grammar so that if a control constraint construct was selected, 
then the construct must contain at least one constraint. The current control constraint 


rule and its smallest corresponding result are shown in Figure 6-16. 





IMPLEMENTATION 
GRAPH 
ag Go id [*:" time) "->" id 
CONTROL CONSTRAINTS 
OPERATOR id 
END 


Figure 6-16. Current Smallest Control Constraint In Context 





The fourth change in the grammar concerned the triggered option in the constraint 
tule. The problem we found with this rule was similar to the problem with the previous 
smallest constraint rule. The previous constraint rule and an example of the smallest 


construct using the triggered option is shown in Figure 6-17. 


constraint 
= "operator" id 
["triggered" [trigger] ["if" predicate) [reqmts_trace]] 
["period" time [reqmts trace] ] 
("finish within" time [reqmts_trace]] 
{constraint_options} 


CONTROL CONSTRAINTS 
OPERATOR id 
TRIGGERED 


Figure 6-17. Previous Triggered Option 
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We changed the triggered option so that if it was selected it requires either a trigger 


or an optional trigger followed by a required "if" predicate. The current constraint rule 


with the smallest possible triggered options are shown in Figure 6-18. 


constraint 


= "operator" id 


["triggered" (trigger | [trigger] 


"if" predicate) 
{["“period" time [regqmts trace] } 


{reqmts trace! | 
["finish within" time [reqmts trace]}] 
{constraint options} 


CONTROL CONSTRAINTS 
OPERATOR id 
TRIGGERED 
BY ALL a,b 

CONTROL CONSTRAINTS 
OPERATOR id 


TRIGGERED 
IF a = 0 


Figure 6-18. Current Triggered Option 


The complete PSDL Grammar shown in Appendix A is the updated grammar which 


reflects the changes we have described. The unplementation of our PSDL editor is con- 


tained in Appendices G through L. 


F. INTEGRATION 


The files which comprise the functional components of the PSDL editor and related 


documentation files reside mostly in the directory /n/suns2/work/caps/syntax_editor. 
These components are: 
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pev executable terminal psdl editor 


pew executable sunview psdl editor 

psdl.as.ssl abstract syntax for psdl editor 

psdl.ad.ssl attribute definitions for psdl editor 

psdl.ci.ssl concrete input for psdl editor 

psdl.lex.ss] lexical file for psdl editor 

psdl.tt.ssl template transfonnations for psdl editor 
psdl.up.ssl §_ unparsing rules for psdl editor 

Makefile shell script to generate an executable PSDL editor 


from the psdl.*.ssl specifications. 
An additional file which initializes the syntax directed editor is: 
/n/suns2/work/caps/.syn_profile 
The on-line manual page instructions for pev is located at: 
/n/suns2/usr/man/manl/pe.1 
The Comell Synthesizer Generator is located at: 


/n/suns2/usr/suns2/local/syn 


When the syntax directed editor is required the user interface creates a new process 
which executes the PSDL editor concurrently with the user interface and any other poten- 
tially active processes. When the designer saves the PSDL prototype from within the 
editor it is initially saved in the caps directory. The user interface directory currently 


simulates the design database and the software database. 


G. USING THE PSDL EDITOR 


When a user selects the syntax directed editor from within the CAPS construction 
menu, he is given the option to view the on-line user’s manual. If instructions are 
requested, then the following description is provided using the UNIX man facility. These 


instructions may also be accessed outside of CAPS by executing man pe. 


81 


NAME 
pe - PSDL syntax directed editor 


SYNOPSIS 
pe 


DESCRIPTION 
pe is a syntax directed editor for the prototype system 
description language (PSDL). This editor was designed to be 


used within the Computer Aided Prototyping System (CAPS). 


The editor provides a simple, mostly regular user interface 
which guides the user painlessly through the structure of a 
correct PSDL program. 


There are 3 primary modes of interaction with the editor. 
Each mode is visually distinctive. 


1. Required Keyboard Input is denoted by a token contained 
in angle brackets, such as <identifier>. 


2. Required Construct Choices are contained within square 
brackets, such as [implementation]. When a construct choice 
is required, the user selects an alternative by pressing the 

tab key followed by typing the alternative or typing an 
unambiguous prefix for the alternative. 


3. Optional Construct Choices are contained within braces, 
such as {description}. The user may select an optional 
construct in the exact same manner as a required choice. The 
user may pass-over an optional construct by pressing the 
return key. 

STRUCTURE TRAVERSAL 
The current position within the structure of a PSDL program 
may be changed by the following: 
“N - next required construct. 
“M or returm - next construct, required or optional. 


“P - previous required construct. 


“H or backspace - previous construct, required or optional. 
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KEYBOARD INPUT 
The current position while entering a particular text item 
via keyboard input may be changed by the following: 
DEL - Delete previous character. 
“D - Delete current character. 
“F - Move the cursor one character to the right. 
“B - Move the cursor one character to the left. 
SAVING THE PROTOTYPE 
Once the prototype description has been entered the file may 
be saved with the following method: 


“X°W - a forms display appears at the bottom of the screen. 


The cursor is positioned at file-name. Enter the name 
psdl.text. 


Press the tab key. The cursor is positioned at file- 


type. Enter the type text . 


Press the tab key again, and enter ESC s to execute the 
command. 


The file has been saved and the forms display is cleared 
from the screen. 


EXITING THE EDITOR 
The editor is exited by typing “C. 
AUTHOR 
Laura J. White 
FILES 
/caps/.syn_profile default parameters for the psdl editor 
/caps/syntax_editor/pev terminal psdl editor 
/caps/syntax_editor/pew sunview psdl editor 
/caps/syntax_editor/psdl.as.ssl abstract syntax for psdl editor 
/caps/syntax_editor/psdl.ad.ssl attribute definitions for psdl editor 
/caps/syntax_editor/psdl.ci.ssl concrete input for psdl editor 


/caps/syntax_editor/psdl.lex.ssl lexical file for psdl editor 
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/caps/syntax_editor/psdl.tt.ssl template transformations for psdl editor 
/caps/syntax_editor/psdl.up.ssl unparsing rules for psdl editor 


SEE ALSO 
White, L. J., The Development of a Rapid Prototyping Environment, 
Master’s Thesis, Naval Postgraduate School, Monterey, California, 
December 1989. 
BUGS 
The text part of the PSDL grammar has not been implemented. 
Identifier is currently used in place of text. 
Some of the constructs remain at the current location, 
instead of advancing forward after a selection is made. The 
visibility behavior of optional constructs within some con- 
structs is still "mysterious" in some instances. This must 
be corrected before a sunview editor implementation will be 
useful. 


Name analysis and type checking is not performed in the 
current version of pe. 


A sample editing session for the construction of a simple prototype is described 
within the rest of this section. We will show the contents of the video screen as the edit- 
ing session progresses. Whenever a user presses a tab the command input prompt 
appears at the top of the screen. The middle of the screen contains the program. The 
current position in the abstract syntax tree is displayed on the bottom line to the left. If 
command mode options are available, they appear to the right of the Positioned at 
display. An option may be selected by entering an unambiguous prefix at the prompt or 
passed over by pressing the return key. Figure 6-19 contains the contents of the video 


screen once the syntax directed editor is started and initialized. 
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[component] 


Positioned at psdl_ components type operator 


Figure 6-19. Sample Editing Session 


We pressed the tab key to obtain the editor’s command prompt. The command 


prompt appears at the top of the display as shown in Figure 6-20. 


COMMAND : 


{component} 


Positioned at psdl_ components type operator 


Figure 6-20. Sample Editing Session 
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At this point, we entered the unambiguous prefix ’o’ for an operator component. The 
command prompt disappears and the template for an operator component is displayed as 


shown in Figure 6-21. 


OPERATOR <identifier> 
SPECIFICATION 

END 

[operator implementation] 


Positioned at id 


Figure 6-21. Sample Editing Session 


We then entered the identifier name for the operator as shown in Figure 6-22. After 
the identifier name is entered, the placeholder for an optional interface construct appears. 


The choices for an optional interface construct are displayed on the bottom of the screen. 


OPERATOR operator 1 
SPECIFICATION 
{interface} 
END 
{operator implementation] 


Positioned at optional interface input output states generic 
exceptions timing info 


Figure 6-22. Sample Editing Session 
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We now chose to describe an input so we pressed the tab key and entered the unam- 


biguous prefix ’i’. The display was updated with the input construct as shown in Figure 


6-23. 





OPERATOR operator 1 
SPECIFICATION 
INPUT 
<identifier> : <identifier> 
END 
[operator implementation] 


Positioned at id list 


Figure 6-23. Sample Editing Session 


After we entered the identifier name of an input and its type as shown in Figure 6-24, 


the optional placeholder for a generic actual parameter is displayed. 


OPERATOR operator 1 
SPECIFICATION 
INPUT 
x : integer {generic actual parameters} 
{requirements} 
END 
[operator implementation] 


Positioned at optional generic actuals enter generic actual parameters 


Figure 6-24. Sample Editing Session 
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At this time we did not wish to specify any generic parameters so we pressed the 
retum key to pass over this option. An optional placeholder for more_type_decls 
appears. We do not wish to specify any more inputs for our operator, nor any require- 
ments for our input so we pressed the return key two more times. PSDL allows zero or 


more interface constructs so the interface option appears again as shown in Figure 6-25. 


OPERATOR operator 1 
SPECIFICATION 
INPUT 
x : integer 
{interface} 
END 
[operator implementation] 


Positioned at optionaleinrertace input output states generic 
exceptions timing info 


Figure 6-25. Sample Editing Session 


We choose to enter timing information for our operator so we press the tab key, enter 
an unambiguous prefix ’t’ and press retum. The placeholders for the optional timing con- 


structs appear, and we are positioned at the first choice as shown in Figure 6-26. 
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OPERATOR operator 1 
SPECIFICATION 
INPUT 
x : integer 
{met} 
{mcp} 
{mrt } 
{requirements} 
END 
[operator implementation] 


Positioned at optional _ met enter MET 


Figure 6-26. Sample Editing Session 


We chose to enter a MET so we pressed the tab key, entered an ’e’ at the command 
prompt and pressed return. The MET construct replaces the optional placeholder and we 


are positioned at integer as shown in Figure 6-27. 


OPERATOR operator 1 
SPECIFICATION 
INPUT 

x 3; integer 
MAXIMUM EXECUTION TIME <integer> 
{mcp} 
{mrt } 
{requirements} 

END 

{operator implementation] 


Positioned at integer 


Figure 6-27. Sample Editing Session 
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We entered a value for the time constraint and pressed return. The optional unit 


placeholder appeared as shown in Figure 6-28. 





OPERATOR operator 1 
SPECIFICATION 
INPUT 

x : integer 
MAXIMUM EXECUTION TIME 10 {units} 
{mcp} 
{mrt } 
{requirements} 

END 

[operator implementation] 


Positioned at optional unit milliseconds seconds minutes hours 


Figure 6-28. Sample Editing Session 


We selected milliseconds as our units by pressing the tab key then entering the 
unambiguous prefix ’mil’. After that we chose not to enter any more timing information 
or any requirements so we pressed return until we were given the opportunity to enter 
another interface construct. We chose not to enter any more of these so we pressed the 


return key again. We are now positioned at an optional keywords construct as shown in 


Figure 6-29. 
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OPERATOR operator 1 
SPECIFICATION 
INPUT 
x : integer 
MAXIMUM EXECUTION TIME 10 MS 
{keywords} 
END 
{operator implementation] 


Positioned at optional keywords enter keywords 


Figure 6-29. Sample Editing Session 





We chose not to enter any keywords so we pressed the retum key. An optional 
description placeholder appeared which we passed over. After that, an optional axioms 
placeholder appeared which we also passed over. We were then positioned at an opera- 


tor implementation as shown in Figure 6-30. 


OPERATOR operator 1 
SPECIFICATION 
INPUT 
x : integer 
MAXIMUM EXECUTION TIME 10 MS 
END 
[operator implementation] 


Positioned at operator _ impl psdl_ implementation ada_implementation 


Figure 6-30. Sample Editing Session 


, ; 


We selected a psdl implementation and the appropriate template for the implementa- 


tion appeared as shown in Figure 6-31. 


OPERATOR operator 1 
SPECIFICATION 
INPUT 
x : integer 
MAXIMUM EXECUTION TIME 10 MS 
END 
IMPLEMENTATION 
GRAPH 
<identifier> .<identifier>-><identifier> 
{data stream} 
{timer} 
{control constraints} 
{description} 
END 


Positioned at id 


Figure 6-31. Sample Editing Session 


At this point we could continue to describe the implementation of our operator in the 


same manner as we did with the specification part, but we chose to exit the editor. 


The PSDL editor uses a very small subset of the capabilities provided for an editor 
using the Cornell Synthesizer Generator. Simplicity and ease was a primary goal for our 
editor. This goal caused us to intentionally design our editor so that a very small subset 


of traversal commands would be required to use the editor effectively. 
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H. FUTURE WORK 


The following items were either not completed in the initial draft of the editor due to 


time constraints or were identified as a result of testing. 
1) The text rule in the PSDL grammar still requires implementation. 


2) The concrete input syntax should be expanded so that a complete PSDL program may 
be parsed. An existing file can only be read into the syntax directed editor if concrete 


input syntax has been specified for the complete grammar. 
3) Name analysis and type checking still require implementation. 


4) The video version of the PSDL editor highlights the locator and the placeholder. The 
highlighted locator is a feature provided by the Cornell Synthesizer Generator. This 
feature is inconsistent with the editor we designed and confuses the user. The locator 


should not be visibly displayed. 


5) The inconsistencies with placeholders must be corrected to provide a useful editor 
which provides a Sun version of the editor which utilizes the mouse, pop-up windows 
and scrolling windows. Once these inconsistencies are eliminated, the editor designer 
need only recompile the editor specifications with a SUN option flag or a X option flag in 


the Makefile to provide a graphic interface. 


6) The current version of the editor has been integrated into CAPS in a very simple 
manner. More sophistication in terms of its interaction with the design database, 
software base and the graphic editor is necessary to meet the requirements of the current 


design. 
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Vil. THE SOFTWARE DATABASE SYSTEM 


The Software Database System consists of the following tools: 

- the Design Database 

- the Software Base 

- the Software Design Management System 
This system provides for the utilization of reusable prototype designs and reusable 
software components during the rapid prototyping process. These tools have not yet 
been integrated into CAPS. This is an important area which requires follow-on design 


and implementation. This chapter is included here for completeness in describing the 


development of our environment. 


A survey of existing database management methodologies and systems has been 
conducted to determine the primary features required to support our software database 
system. Feasability studies have also been conducted to refine the requirements and 


interaction within CAPS using one selected database management system. 


A. REUSABILITY 


The key motivation for our software database system is reuse. The benefits and 
advantages of reusability include: 

- improved software quality and maintenance 

- increased programmer productivity and efficiency 


- faster software development 
- lower development costs 
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Galik [13} provides us with a brief synopsis of the following areas of research 
regarding software reusability: 

- reusability and abstraction 

- Ada and reusability 

- the Ada software repository 

- object-oriented programming and reusability 

- a keyword based retrieval system 


- a reusable software library 
- classification and retrieval 


Galik found that researchers generally agreed that a greater use of abstraction 
resulted in greater reusability. Pamas [30] notes that information hiding and abstraction 
generally produces software that is well-defined and well-documented, which tends 


towards reusability. 


Reusability was a primary concern in the design of the Ada programming language, 
which supports both abstraction and information hiding. Ada separates the interface 
specification of a program unit from its implementation. These specifications determine 
how program units may be reused. Both the specification and the implementation parts 
may be reused. Ada provides a package subprogram which strongly supports the 
development of abstract data types. A key feature of Ada is the generic unit which is the 


primary mechanism provided in the language for building reusable software components. 


The Ada Software Repository [31] is a public-domain collection of Ada programs 
and information. The software components are categorized by their high level applica- 
tions. A programmer must scan an index, then browse each of the potential candidates 


for its suitability. This can be a very time-consuming process. 
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Johnson and Foote [32] state that object-oriented programming promotes software 
reuse. They state that class definitions provide modularity and information hiding which 
supports reuse. Class inheritance supports reuse by permitting classes to be modified to 


form subclasses. 


Matsumoto [33] describes an object-oriented retrieval system being developed which 
is a simple keyword based system. A synonym library provides a standard normalized 


keyword for retrieval based on user input. 


A Reusable Software Library (RSL) has been developed at Intermetrics, Inc. The 
RSL [34] is comprised of the RSL database and four subsystems which are: 

- a library management subsystem 

- auser query subsystem 


- a software componenent retrieval and evaluation subsystem 
- a software computer-aided design subsystem 


This library classifies components by a set of attributes. Retrieval is an interactive 
process which identifies components which perform a desired function. The user assigns 
relative importance to the attributes of the components and the system evaluates and rates 


components based on the user’s needs. 


Prieto-Diaz and Freeman [35] state that the proper classification of reusable software 
components is the central issue in making reusability an attractive approach to software 
development. They propose an integrated classification scheme that is embedded within 
the retrieval system. An evaluation mechanism is provided to help users discriminate 
between similar components in the software base and to allow users to select components 
which will require minimal modifications. Their algorithm is shown in Figure 7-1. This 


algorithm provides the basis for our design in retrieving reusable components in CAPS. 
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begin 
search library 
if identical match then 
terminate 
else 
collect similar components 
for each componenet com 
compute degree of match 
end 
rank and select best 
modify component 
endif 
end 


Figure 7-1. Code Reuse Process 


The classification scheme proposed by Prieto-Diaz utilizes a description of software 
components with a sextuple containing attributes which capture the functional charac- 


teristics of the component. 


B. REQUIREMENTS 


The requirements for our software database system were defined to provide the fol- 
lowing capabilities: 


- tostore PSDL designs and software components 

- toretrieve designs and software components for editing 

- to retrieve designs and software components for review 

- to delete designs and software components 

- the CAPS user interface should interact with the software 
database system in such a way that the software management system 
is transparant to the protoype designer. 
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C. SURVEY OF DATABASE MANAGEMENT TECHNOLOGIES 


Relational, Hierachical, Network and Object-Oriented database management systems 
were evaluated by Galik. He found that the first three did not support efficiency or pro- 
ductivity due to the following characteristics: 

- fixed set of structures and operations 

- limitations of a fixed set of predefined types 

- redundancy of data 


- lack of abstraction capabilities 
- schema not easily modifiable 


The object-oriented database management systems attempt to provide facilities 
which permit the definition of any structure or operation rather than a fixed set. Proper- 
ties of an object-oriented database management system include: 

- abstraction 

- extensibility 


- persistency 
- active data ( 


The object-oriented approach was selected as the most suitable technology for the 
implementation of our software database system. Within this type of system an object is 
considered as a description of an entity in some application domain. It may be a simple 
atomic representation or a composite structure. An object has a unique identifier and a 
set of operations which are defined for that object. Objects which are similar are grouped 
into classes. A class is also considered as an object. Class hierarchy and inheritance of 
properties permits the definition of subclasses which may inherit all properties of the 


class but may have additional local properties. 


Vbase, a product of Ontologic Inc. was selected for CAPS. Vbase runs in the Unix 


environment on Sun workstations. The Wbase system consists of the following 


98 





components: 
- the Vbase Database of persistent objects 
- the Type Definition Language (TDL) provides the data model or 
conceptual schema for applications 
- aC Object Processor which is the Vbase data manipulation language 


- an Integrated Tool Set (ITS) 
- an Object SQL which is the query facility for the retrival of objects 


The process of defining a typical database design includes: 
- define the objects 

- define the properties of the objects 

- define frequent operations performed on objects 

- describe the objects and their properties in TDL 

- compile and debug the TDL definitions 


- develop COP routines which implement the defined operations 
- compile and debug the COP programs 


Galik and Douglas successfully implemented Vbase systems for the storage and 


retrieval of objects in the software base and the design database. 


D. FUTURE INTEGRATION 


We currently divide the software design management system into two COP com- 
ponents, one for the software base and one for the design database. The purpose of the 
design database and the interaction between the designer and the design database requires 
further refinement. This process has not been extended beyond the description provided 
by Douglas. We have extended and refined the design for the integration of the software 


database system from that previously described by Galik. 


The software design management system for Ada components and the Vbase data- 
base of reusable Ada software components should reside in the directory 


/caps/software_base. The software design management system for PSDL prototype 
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specifications and the Vbase database of reusable prototype designs should reside in the 
directory /caps/design_database. The implementation defined filenames used in the 
feasibility studies, are suitable for the integration which we have currently defined. These 
files should exist as temporary data components with lifetimes based on their applicabil- 
ity. 

The input file for the software base retrieval is currently a PSDL specification part 
and the output is an Ada component. The input file for a design database retrieval 
currently contains the desired properties of a PSDL description and the output is a com- 
plete PSDL description. We will describe the interaction of the software design manage- 


ment system in the context of constructing a prototype from within the graphic editor. 


When a designer selects the graphic editor from the construction menu in the user 
interface, both the user interface process and the graphic editor process remain active. 
The designer may describe a prototype using a single operator. If the designer wishes to 
determine if a reusable Ada component already exists in the database for the operator just 
defined, then he selects the search button in the graphic editor. The search function 
should call the store function which will cause a file NewNode.0] to be created which is a 
PSDL specification for the operator. The search function should make a copy of the 
PSDL specification into the file PSDL_SPECS. The search function should then execute 
the COP program which represents the database management system for the software 
base. If a match is not found in the software base, then the search function should 
remove the temporary file PSDL_SPECS and cause a message to be displayed in the mes- 
sage panel which states that a match was not found. If a match is found, then that reus- 


able component now resides in the file SB OUT and the search function should open a 
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popup window which overlays the top portion of the graphic editor. This window should 
not overlay the message panel or the drawing space. If a single match was found, then a 
statement which reflects that case is displayed and the designer is given an option to 
browse the component, edit the component, save the component or to quit the search pro- 
cess. If the designer chooses to browse the component, then the command more 
SB OUT is automatically executed within the popup window. If the designer chooses to 
edit the component, then ideally an Ada syntax directed editor should automatically be 
executed on the file SB OUT within the popup window. If the designer chooses to save 
the component then the modified component should be stored so that the designer may 
choose to discard it or add it to the software base during the quit process of the user inter- 
face. The component should also be appended to the file SB PACKAGE which will be 
referenced by the translator during the execute process. If the designer chooses to quit 
the search process, then the files PSDL_SPEC and SB_OUT are removed and the pop-up 


window is closed. 


The designer continues the construction and search processes until a complete PSDL 


description is represented by a tree which contains Ada components at all of its leaves. 
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VI. THE TRANSLATOR 


A. PREVIOUS DESIGN 


The purpose of the translator is to produce an Ada translation of a PSDL prototype 
description. The translator performs lexical analysis of the internal textual representation 
of a PSDL system prototype, parses the prototype description and constructs an abstract 
syntax tree, and then evaluates the attributes of the tree to provide an Ada representation 


which utilizes PSDL abstract data types. 


An Ada translation is a template with five major sections derived from the PSDL 
input program: 

- exception declarations 

- atomic operator driver headers 

- atomic subprograms 


- PSDL operator specification packages 
- PSDL atomic operator driver subprograms 


The exception declarations define the PSDL_EXCEPTION data type and all of the 
PSDL exceptions which may be raised in a PSDL program. The atomic operator driver 
headers are the interfaces for the subprogram names which will be called by the static 
and dynamic schedules. The atomic subprograms section contains all of the atomic level 
Ada code drawn from the reusable software base or entered by the designer during the 
construction of the prototype. The PSDL operator specification part contains Ada pack- 
age specifications for all of the composite PSDL operator specifications. The PSDL 


atomic operator drivers are Ada subprograms which execute the atomic subprograms in 
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terms of the PSDL control constraints specified for each operator. The Ada package tem- 


plate is shown in Figure 8-1 [14]. 





package TL is 


type PSDL_EXCEPTION is (psdl_excpl, psdl_excp2,..., psdl_excpN; 
excpl, excp2,..., excpN : exception; 


procedure atomic _driverl; © 
procedure atomic driver2; 


procedure atomic _driverN; 





end TL; 


with PSDL SYSTEM; 
use PSDL SYSTEM; 


package body TL is 


atomic procedures drawn from the software base 


PSDL operator specification packages 


PSDL atomic operator driver procedures 


end TL; 








Figure 8-1. TL Package Template 
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The PSDL abstract data types implemented for the translator are: 
- Gata streams 
- State variables 


- timers 
- exceptions 


There are two kinds of data streams in PSDL: sampled streams and data flow streams. A 
sampled stream is a data stream which has a persistent data value until it is overwritten 
with another value. When a value is read from a sampled stream, the value remains on 
the sampled stream. A data flow stream is a data stream which may only be written if the 
stream is empty and can only be read when a value exists on the data flow stream. Read- 
ing the value of the data flow stream consumes the value. Data streams have two defined 
error conditions, BUFFER_UNDERFLOW and BUFFER_OVERFLOW. The first error 
occurs if an attempt is made to write onto a data flow stream which has a value. The 
second error occurs if an attempt is made to read an uninitialized sampled stream or an 
empty data flow stream. The four different PSDL constructs which declare data streams 
are: 

- input attribute 

- output attribute 


- states attribute 
- streams 


State variables are data streams which are automatically initialized. 


A timer is a built-in data type which behaves as a simple digital stopwatch used to 
measure elapsed times. The operations available on timers include: 

- Start 

- stop 


- read 
- reset 
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A timer may be represented by a state machine which has three states as shown in Figure 


8-2 [14]. 


RESET START STOP 





STOPPED 
STATE 





Figure 8-2. Timer State Machine 


The read operation does not cause any change of state. A timer may be read at any 
time regardless of the current state. The value returned when reading a timer is always 
the amount of time that a timer has spent in the running state since the last transition 


from the initial state. 


PSDL exceptions are special data types which may be written to any data stream 


without regard for the data stream’s normal data type. 
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B. PREVIOUS IMPLEMENTATION 


The translator is comprised of two main modules: the Kodiyak translator 


specification and the Ada package which implements the PSDL abstract data types. 


The translator specification was implemented using the Kodiyak translator generator. 
Kodiyak is a UNIX based tool which was built on top of LEX and YACC. A Kodiyak 
program has three distinct parts. The first part provides the lexical rules for the source 
language. The second part provides the declarations for the attributes in the abstract syn- 
tax. The third part provides the attribute equations which are used to determine the 
values of the attributes in the abstract syntax tree. Four passes of the abstract syntax tree 


are performed. A pass is defined as a traversal from top to bottom or from bottom to top. 


The first pass is a depth-first traversal of the tree from the root. Pass one collects the 
following information for each node in the tree: 
- all operator names and their parent names 


- all data stream names and whether they are sampled or data flow streams 
- all exceptions declared in the program 


The second pass traverses the tree from the leaves back to the root. The information 
determined for each node during pass one is synthesized up to the root. This information 
is collected in the Kodiyak data structure for a map. The global map contains the contex- 


tual data of the PSDL program. 


The third pass routes the global map created in pass two back down the tree to start 
the translation process. Translation occurs at each node in the tree. The translations are 


to strings of Ada code. The leaves of the tree inherit the Ada translations. 
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The fourth pass collects the Ada translations from the leaves of the tree and con- 
structs composition groups of translated Ada code. When the fourth pass reaches the root 


of the tree, then all the translation information is stored in the root. 


C. MODIFICATIONS 


We modified the design described by Altizer to improve the efficiency of the transla- 
tion and compilation processes. This design modification has not been implemented at 
this time. The user interface was to insert the actual source code for reusable com- 
ponents which were used in the construction process into the Ada translation. It has 
since been realized that this should not be necessary. The reusable components should 
have source views and executable views. The designer may use the source views during 
the construction phase but then the executable views should be formed into a package 
which will be linked with the translator when the final executable prototype is created. 
The package of reusable components should have a unit name, such as SB_PACKAGE, 
and the translator must contain an Ada WITH SB_PACKAGE statement. This means 
that generic reusable components are instantiated and compiled when selected during the 


construction phase. 


We also modified the implementation of the translator to require and recognize the 
END statement which brackets the PSDL IMPLEMENTATION ADA statement. This 
was necessary due to the design modification of the PSDL language which we described 


in chapter six. 
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D. INTEGRATION 


The components which comprise the translator are contained in the directory 
/caps/translator. These files are: 


translator.k kodiyak translator specifications 
psdl_system.a Ada implementation of PSDL abstract data types 


The data components which are used as input to the translator and the output produced 
by the translator are stored in the directory /caps/prototypes. These files are: 


psdl.txt input 
tl.a output 


The Kodiyak Compiler resides in the subdirectory Kodiyak. An executable translator 
may be generated with kc translator.k in the subdirectory. The executable translator will 
have the file name translator. The executable translator must be moved to the parent 
directory. 
The on-line manual page for Kodiyak is located at: 
/n/suns2/usr/suns2/man/manl/kodiyak.1 
The translator specifications and the Ada implementation of the PSDL data types are 


contained in Appendices M and N. 
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IX. THE STATIC SCHEDULER 


A. PREVIOUS DESIGN 


The purpose of the static scheduler is to schedule the PSDL operators in a prototype 
description so that the tume constraints are satisfied during execution. If a feasible 
schedule exists, then the static scheduler creates an Ada program which controls the exe- 
cution of these operators. A data flow diagram for the static scheduler is shown in Figure 


9-1. 
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Figure 9-1. Static Scheduler 
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The Preprocessor reads an intemal textual PSDL file and outputs a file which con- 
tains a list of all composite and atomic operators with their relevant characteristics such 


as their timing constraints and link information. 


The Decomposer reads the output of the preprocessor and creates a file which only 


contains the atomic operators and their relevant characteristics. 


The File_Processor reads the file of atomic operators and creates a graph structure 
which represents all of the atomic operators with critical timing constraints. It also 


creates a file which lists the atomic operators without critical timing constraints. 


The Topological_Sorter uses the graph structure created by the File_Processor to 
build and output a precedence relationship that specifies which operators must complete 
their execution before other operators may start executing. This precedence relationship 


is always determined but is only used by some of the scheduling algorithms. 


The Harmonic_Block_Builder calculates the periodic equivalents of the sporadic 
operators which have no defined periods. Then it checks if a harmonic block can be 
found for a single processor. If a harmonic block is found then it calculates and outputs a 


harmonic block length. 


The Operators_Scheduler uses the graph structure, the precedence list and the har- 
monic block length to determine if a feasible schedule exists. If a schedule is feasible, 


one of six scheduling algorithms may be used to buuld a schedule. 


The Exception_Handler manages the exceptions which pertain to critical operators 


scheduled by the static scheduler. 
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The static scheduler produces two outputs. One output is an Ada program which 
contains a schedule for all of the operators in a software system prototype with critical 
timing constraints. The other output is the file which contains the names of the atomic 


operators in the prototype which do not have any critical timing constraints. 


B. IMPLEMENTATION 


The static scheduler has been described and incrementally implemented by Marlowe 
[15] and Kilic [16]. The static scheduler preprocessor was implemented with Kodiyak 
specifications. The details of the Kodiyak Compiler were described in the previous 
chapter. The output of the preprocessor will be processed to produce an output which 
only contains atomic operators. An example of the atomic operators and _ their 
corresponding graph structure which would be created by the file processor are shown in 
Figure 9-2. There are currently three of six scheduling algorithms implemented in the 
static scheduler. The three algorithms which have been implemented are : 

- the harmonic block with precedence constraints scheduling algorithm 


- the earliest start scheduling algorithm 
- the earliest deadline scheduling algorithm 


The three scheduling algorithms which remain to be implemented are: 
- the fixed priorities scheduling algorithm 


- the minimize maximum tardiness with early start tumes scheduling algorithm 
- the rate-monotonic priority assignment scheduling algorithm 


These algorithms are explained in detail by Kilic. He implemented the static scheduler 
as a stand-alone tool which required modifications when integrated into CAPS. The pri- 


mary capabilities of the two versions remain the same. 
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Figure 9-2. Decomposer Output And Graph Structure ( 


C. MODIFICATIONS 


The input to the static scheduler’s preprocessor is a PSDL prototype description. 
The Kodiyak specifications for the preprocessor were modified to reflect the change in 
the PSDL grammar described in chapter six. An END statement is required to bracket an | 


IMPLEMENTATION ADA statement. 


The Ada implementations were modified to better serve the purposes of an integrated | 
tool within CAPS. An algorithm selection menu and several of the notification messages 


were removed. The current design of the static scheduler in CAPS which interacts with a 


112 





designer applies the different scheduling algorithms in an implementation defined order 


until a solution is found or until all algorithms have failed to produce a schedule. 


During the integration and testing of the static scheduler three major areas were 
identified for future modifications. The first is to develop some selection mechanism 
which matches the prototype design to an optimal scheduling algorithm. The selection of 
an algorithm will still remain transparent to the designer, but should become more 
efficient if the order of the algorithms are selected more intelligently. The second is that 
the decomposer module still remains to be implemented. Another area of future work 
which was originally identified by Marlowe is to define an algorithm and implementation 


which determines a harmonic block length for multiple processors. 


D. INTEGRATION 


The components which comprise the static scheduler are contained in the directory 


/caps/static_scheduler. These files are: 


decomposer_b.a - validates and decomposes output of preprocessor 
decomposer_s.a - validates and decomposes output of preprocessor 
driver.a - interface for stand-alone static scheduler 
e_handler_b.a - exception routines used by driver 
e_handler_s.a - exception routines used by driver 
files.a - global types and declarations for all ss programs 
_b.a - file processor 
_S.a - file processor 
graphs_b.a - generic type graph structure 
graphs_s.a - generic type graph structure 
hbb_b.a - harmonic block builder 
hbb_s.a - harmonic block builder 
ke - script to compile static scheduler preprocess pre_ss.k 
pre_ss - executable preprocessor 
pre_ss.k - kodiyak specifications for preprocessor 
scheduler_b.a - operators_scheduler 
scheduler_s.a - operators_scheduler 
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sequence_b.a - generic type list structure 


Sequence_s.a - generic type list structure 
Static_scheduler - executable static_scheduler 

t_sort_b.a - topological sorter 

t_sort_s.a - topological sorter 


The Kodiyak Compiler resides in the subdirectory /caps/static_scheduler/Kodiy ak. 
The preprocessor is generated by compiling with kc pre_ss.k in the Kodiyak subdirec- 
tory. The executable preprocessor pre_ss must be moved to the parent directory 


/caps/static_scheduler. 


The user interface executes pre_ss with the command line equivalent: 
pre_ss <file name> -o operator.info 
The Ada components of the static_scheduler are compiled by: 


a.make static_scheduler -f *.a -o static_scheduler 
( where *.a uses all files listed above which have a.a suffix ) 


The static_scheduler is executed in the user interface by the command line equivalent: 
static_scheduler 


files.a is dependent upon: 
vstrings 
sequences 
graphs 


decomposer_b.a, decomposer_s.a, e_handler_b.a, e_handler_s.a, 
fp_b.a, fp_s.a, hbb_b.a, hbb_s.a, scheduler_b.a, scheduler_s.a, 
t_sort_b.a, t_sort_s.a are all dependent upon: 

files (files.a) 


driver.a is dependent upon 
decomposer (decomposer_b.a, decomposer_s.a) 
exception_handler (e_handler_b.a, e_handler_s.a) 
file_processor (fp_b.a, fp_s.a) 
harmonic_block_builder (hbb_b.a, hbb_s.a) 
operator_scheduler (scheduler_b.a, scheduler_s.a) 
topological_sorter (t_sort_b.a, t_sort_s.a) 
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pre_ss creates operator.info 

decomposer reads operator.info and creates atomic.info 
File_processor reads atomic.info 

File_processor creates non_crits 

Operator_scheduler creates ss.a 


The components which comprise the static scheduler are contained in Appendices O 


through AE. 
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X. THE DYNAMIC SCHEDULER 


A. PREVIOUS DESIGN 


The purpose of the dynamic scheduler was to coordinate the execution of all opera- 
tors and their debuggers during the execution of a prototype. The static schedule, the 
non-time-critical operators and the debugging system were all components of the 


dynamic scheduler. 


B. MODIFICATIONS 


There was not any previous implementation of a dynamic scheduler. The previous 
design of the dynamic scheduler has been modified so that it only creates a schedule for 
the non-time-critical operators of a PSDL prototype description. A file which lists these 
operators is provided by the static scheduler. The dynamic scheduler is not concerned 
with the activities of any time-critical operators or with any special component which 
represents a debugging system. This modification still performs the functions required 
and provides for a simplified conceptual model of the execution support system. The 
dynamic schedule executes its operators in a sequential manner during the slack times 
between the execution of time-critical operators controlled by the static schedule. On a 
single processor each non-time-critical operator completes its execution before another 


non-time-critical operator is started. 
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C. INTEGRATION 


The component which comprises the dynamic scheduler is located in the directory 
/caps/dynamic_scheduler. The file is dynamic_scheduler.a. The dynamic_scheduler is 
invoked by the user interface when the designer selects the execute option in the main 
menu. The dynamic scheduler reads the file non.crits which was produced by the static 
scheduler and creates a dynamic schedule which is placed in the file ds.a. The dynamic 
schedule, static schedule and Ada translation of the PSDL prototype are all compiled and 
linked into an executable data component which is currently called prototype. The 


dynamic scheduler is contained in Appendix AF. 
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XI. THE DEBUGGER 


A. PREVIOUS DESIGN 


The purpose of the debugger was to provide run-time support for the execution of 
prototypes. The debugger was designed as two components: one for the static scheduler 
and one for the dynamic scheduler. The debugger processed errors encountered by either 
scheduler. The static debugger would process errors while attempting to create a 
schedule and the dynamic debugger would process errors that occurred while the opera- 
tors were executing. Both debuggers were to operate in a similar manner. They would 
report an error condition, if possible correct the error, then permit the user to dictate 
whether execution should continue or terminate. All information relating to an error 


would also be written to a file for recall. 


The static debugger was to process the following errors [17]: 


- MET_Not Less_Than_MRT 

- MET_Not_Less_Than_ Period 
- No_Initial_Link_Op 

- No_Matches_Found 

- MCP_NOT_Less_Than_MRT 
- MET_Not_Less_Than_MCP 

- No_Base_Block 

- Fail_ Half Period 

- Bad_Total_Time 

- Ratio_Too_Big 

- Over_Time 

- Invalid_Schedule ) 
- Schedule_Error 
- MET_Required 

- MET_GT_Parent 

- MET_Sum_GT_Parent 
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- Crit_Op_Lacks_MET 
- Crit_Op_Lacks_ MET 
- Excessive_Constraints_ Altered 


The dynamic debugger was intended to process errors identified during run-time exe- 
cution of both time and non-time critical operators. These errors were [17]: 

- Buffer_Underflow 

- Buffer_Overflow 

- Unprocessed_Exception 


- Insufficient_MET 
- Excessive_Execution 


The dynamic debugger was to provide a user with an option to adjust the MET of an 
operator without terminating the execution of the prototype or to terminate the execution 


of the prototype. 


B. PREVIOUS IMPLEMENTATION 


The previous implementation consisted of two Ada programs. The implementation 
lacked the maturity required for integration into CAPS. The researchers involved with 
the parallel] development of the static scheduler and the dynamic scheduler, Kilic and 
Palazzo, found the previous design and inplementation of the debugger too awkward to 
integrate with their tools. The previous implementation has not been integrated into 
CAPS but should provide guidance in the design of the static and dynamic schedulers, 


and consideration in a more complete design of the debugger. 
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C. MODIFICATIONS 


The design and implementation of the static debugger was essentially an exception 
handler and was partially implemented as a component of the static scheduler. The 
errors identified by Wood which were not implemented in the current static scheduler 


require further evaluation to determine their relevance. 


The design and implementation of the dynamic debugger essentially provided an 
interface with the user to adjust the METs of operators which fail to satisfy their time 
constraints. The implementation did not contain any mechanism for actually effecting 
this change. The effect of changing the MET for one particular operator must be con- 
sidered in terms of the static schedule. We have not currently determined whether or not 
a new static schedule should be built when a MET is changed in the run-time debugger. 
We also suspect that arbitrarily changing a MET in the run-time debugger may result in a 
prototype design which might not have a feasible static schedule. Possibly, the debugger 
should evaluate the side effects which will result in changing a MET and establish boun- 
daries to the user. Care must be taken to ensure that the user is not allowed to modify the 
prototype design in the run-time debugger thus causing the prototype to self-destruct. 


These issues deserve careful consideration in the further design of a run-time debugger. 
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XI. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 


Our research has contributed towards the development of a rapid prototyping 
language and a rapid prototyping environment. The necessary characteristics, features, 
and difficulties with the development of such a language and environment have been 
refined as a result of the long term research effort which this thesis describes partially. 
The support towards software development and evolution which a rapid prototyping 
environment may or should provide and some of the important issues encountered with 


its development have also been better defined. 


This thesis research encorporated the first attempt to assemble the previous work on 
individual tools into one integrated environment. This required a top-down view of the 
environment necessitating a much more comprehensive understanding of the major 
issues of a rapid prototyping environment than is required for a bottom-up view of a par- 
ticular tool. As the integration progressed more and more knowledge of the design, 
structure and implementation of previously developed tools and knowledge of the tech- 
nologies used in their implementation was required to enable the redesign, partial imple- 
mentation and adaption into an integrated environment. Our current state of implementa- 
tion reflects an ability to work in or understand PSDL, Ada, C, Pascal, Unix, Kodiyak, 


SSL and Sunview Graphics. Future modifications may also require this same knowledge. 
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The current state of development supports the view that it is impossible to com- 
pletely state the requirements of a system in advance and that the development process 
itself changes the perceptions of what is possible or necessary. This has been reflected in 
previous chapters. The actual development of the tools and the environment has been 
performed primarily by many graduate students over a long period of time. Student con- 
tributions are constrained to relatively short time periods. Consequently, the design of 
CAPS has continued to evolve over time as different people have become involved. This 
work does not always reflect the ideal solution to a particular issue or implementation 
problem. It has been influenced by the early decision to permit students enough latitude 
to make the best use of their backgrounds and to permit them to explore the areas which 
interest them most. As the design and implementation have matured, the learning curve 


associated with an overall understanding of the environment has increased. 


Related research areas currently in progress at the Naval Postgraduate School are: 
- a graph model for software maintenance 

- automatic merging of prototype versions 

- generation of a CAPS interface with X windows 


- prototype analysis and schedule matching 
- survey and evaluation of current rapid prototyping processes 


B. RECOMMENDATIONS 


Version control for our implementations is currently performed manually. The pre- 
vious lack of proper documentation and version control created significant difficulties 
during the initial stage of our integration. Previous incorrect versions of many of the 


implementations described in this thesis exist outside of the configuration used here. In 
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many cases, the implementations used in our integration are the only correct versions 


which exist on our system. 


For evolution purposes implementation path names have been specified fully so that 
a new installation or a change in the system configuration may be effected by making 
global substitutions of the old system path names with the new system path names. Sys- 
tem dependent or configuration dependent path names exist in the following files: 

- Caps.c 

- graph.c 

- nodes.p 

- ge 

- fp_b.a 


- scheduler_b.a 
- dynamic_scheduler.a 


Significant follow-on research is required in the areas of view consistency, reusabil- 
ity, and run-time debugging. These issues and additional areas have been defined in 


greater detail within applicable chapters. 
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APPENDIX A PSDL GRAMMAR 


Optional items are enclosed in [ square brackets ]. Items which may appear zero or 
more times appear in { braces }. Terminal symbols appear in " double quotes ". Group- 


ings appear in ( parentheses ). 


psdl 
= {component } 


component 
= data_type 
|} operator 


data _ type 
= "type" id type spec type impl 


operator 
= "operator" id operator spec operator impl 


type spec 
= "specification [type _decl] {"operator" id operator spec} 
[functionality] "end" 


type impl 
= "implementation ada" id "{" text "}" "end" 
| "implementation" type name {"operator" id operator impl} "end" 


operator spec 
= "specification" {interface} [functionality] "end" 


operator impl 
= "implementation ada" id "{" text "}" "end" 


| "implementation" psdl_impl 


type decl 
= id list ":" type name (7, " sd0l is eee ence 


functionality 
= [keywords] [informal_desc] [formal desc] 
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psdl impl 
= data flow _ diagram [streams] [timers] (control _ constraints] 
{informal desc] "end" 


type name 
= id 
| id "(" type decl "j" 


interface 
= attribute [reqmts trace] 


fa list 
= id {"," id} 


keywords 
= "keywords" id list 


informal desc 
= "description" "{" text "™}" 


formal desc 
= "axioms" "{" text "}®" 


data_flow diagram 
= "graph" link {link} 


streams 
= "data stream" type _decl 


timers 
= "timer" id list 


attribute 
= input 
| output 
{| generic param 
| states 
| exceptions 
| timing info 


input 
= “input”, type decl 


output 
= “output" type decl 


generic param 
= "generic" type decl 


states 
= "states" type decl "initially" expression list 
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exceptions 
= "exceptions" id list 


timing info 
= ["maximum execution time" time] [{"minimum calling period" time] 
("maximum response time" time] 


reqmts trace 
= "by requirements" id list 


link 
=m 3d "." adit =" time] “=2" ad 


control constraints 
= "control constraints" constraint {constraint } 


constraint 
= "operator" id 
("triggered" (trigger | {trigger] "if" predicate) [{reqmts trace] ] 
["period" time [reqmts trace] ] 
["finish within" time [reqmts trace] ] 
{constraint options} 


trigger 
= "by all" id list 
|) “by some" Hideia se 


constraint options 
= "output" id list "if" predicate [reqmts trace] 
| "exception" id ["if" predicate] [reqmts_ trace] 
{ timer _op id {"if" predicate] [reqmts trace] 


timer op 
= "read timer" 
| "reset timer" 
| "start timer" 
1} “stop timer" 


expression list 
= expression {"," expression} 


time 

= integer [unit] 
unit 

= "mst 

| "sec" 

| "min" 

| "hours" 
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expression 


constant 
id 


type_ name "." id "(" expression list ")" 


predicate 


simple expression 
simple _ expression rel_op simple expression 


simple expression 


real 


integer 


[sign] integer [unit] 
[sign] real 

("not"] id 

string 

("not"] "™(" predicate ")" 
("not") boolean constant 


"and" 


nen 
Wen 
an 
8 
WF a 
n/a 


integer "." integer 


digit {digit} 


boolean constant 


"true" 
"false" 


numeric constant 
= real 


constant 


integer 


= numberic constant 


boolean _ constant 
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sign 
a wat 


char 
= any printable character except "}" 
digit 
= "0 g" 
letter 
Nae Ze 


(ae; ees 
| 


alpha _numberic 


= letter 

| "dzgat 
nite 

= letter {alpha_numeric} 
string 

— nnn {char} "™"" 
text 


{char } 
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APPENDIX B USER INTERFACE 


litt td tte tt tte th tet ee eee ee eee Ee Te CT ETP S CS CCCCSCLSCSCLCCCCCCCT CL 


FILE: 
AUTHOR: 
DATE: 


caps.c 


Laura J. White 
29 December 89 


PURPOSE: CAPS - User Interface 

eee AR AKRKARKAKKKRAA AK KKK AK KAKKERKKKKKRKAKKK KK KKKKKREKEEKEKKEKEREKEEEKEKKKKAKKKHE / 
#include <stdio.h> 
#include <sys/file.h> 
#include <sys/wait.h> 
#include <signal.h> 


/* system dependent pathnames */ 


#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 


#define 


#define 


#define 


#define 


#define 


SERVER 
SHELL 

R_SHELL 

TEXT FILE 
ADA_COMPILER 
GRAPHIC EDITOR 
SDE 
LOCAL_MANUAL 
REMOTE MANUAL 
TRANSLATOR 
DYNAMIC 

STATIC 

PRE SS 
PSDL_COMPOSITES 
PSDL_ATOMICS 
PROTOTYPE 
MV_TL_ WORK 


MV_TL_HOME 
Mv_SS_WORK 
MV_SS_HOME 
MV_DS WORK 


MV_DS_HOME 


union wait status; 
int code; 


"suns2" 

"/bin/csh" 

"/n/suns2/usr/ucb/rsh" 

"/n/suns2/work/caps/prototypes/psdl.txt" 

"/n/suns2/usr/suns2/VADS/bin/a.make" 

"/n/suns2/work/caps/graphic_editor/ge" 

"/n/suns2/work/caps/syntax_editor/pev" 

"man pe" 

"rsh suns2 man pe" 

"/n/suns2/work/caps/translator/translator" 

"/n/suns2/work/caps/dynamic_scheduler/dynamic_scheduler" 

"/n/suns2/work/caps/static_scheduler/static_scheduler" 

"/n/suns2/work/caps/static_scheduler/pre_ss" 

"/n/suns2/work/caps/prototypes/operator.info" 

"/n/suns2/work/caps/prototypes/atomic.info" 

"/n/suns2/work/caps/prototypes/prototype" 

"mv /n/suns2/work/caps/prototypes/tl.a \ 
/n/suns2/work/caps/tl.a" 

"mv /n/suns2/work/caps/tl.a \ 
/n/suns2/work/caps/prototypes/tl.a" 

"mv /n/suns2/work/caps/prototypes/ss.a \ 
/n/suns2/work/caps/ss.a" 

"mv /n/suns2/work/caps/ss.a \ 
/n/suns2/work/caps/prototypes/ss.a" 

"mv /n/suns2/work/caps/prototypes/ds.a \ 
/n/suns2/work/caps/ds.a" 

"mv /n/suns2/work/caps/ds.a \ 
/n/suns2/work/caps/prototypes/ds.a" 
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main () 


[RRRKKKKKKKKKKAKKKKKKKKKKE KEKE KKK KKRKKK KKK KKKKKKKEKKKKKKKKKKKKKKEKKKKKKKKKKKK 


Function: Main menu for CAPS 
Date: 9 May 89 

Called By: command line 
Calls: 


Side Effects: int code 


construct (), execute(), modify () 


KKK KKK KKK KKK KKK KKK IKK KKK KEK KKK KKK KKK KKK KKK KKK KK KEKE KKKKKKKKEKKKKKKKKKEEKEE | 


{ 
char choice; 
char carriage return; 
int caps done = 0; 


while(!caps done) { 
system("clear") ; 


fprintf(stdout, "\n\n\n\n\n"); 


fprintf(stdout," 
fprintf(stdout, "\n\n"); 
fprintf (stdout, " 
fprintf(stdout, " 
fprintf(stdout, " 
fprintf(stdout, " 


COMPUTER AIDED PROTOTYPING SYSTEM\n") ; 


(c)onstruct\n") ; 
(e) xecute\n") ; 
(m) odify\n") ; 
(q) 112 Ene: 


forintt (Stdout, mo) 
fprinti (stdout, | Select Option: "); 
fscanf (stdin, "%c", &choice) ; 
fscanf (stdin, "tc", &carriage return) ; 
switch(choice) { 
case ‘’c’:; | 
construct (); 
break; 
case ‘e’; 
execute (); 
break; 
case ‘m’:; 
modify (); 
break; 
case 'q’: 
caps_donett; 
break; 
default: 
fprintf(stdout, "\n 
sleep (3); 
break; 


Invalid Choice\n") ; 


} 
system("clear"); : 
exit (0); | 
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int construct () 
[BK RR IK HK KR KK ITI IK KITT I IK IKK KK ITI IOI IKI KOKOK KOI T ITI I KKK IK KKK KOKI KIRK IK IK I IK 


Function: construct selection from caps main menu 
submenu for graphic editor or syntax directed editor 
Date: 6 May 1989 
Called By: main () 
Calls: file /caps/graphic_editor/ge 
syntax editor () 
Side Effects: int code 


file /caps/prototypes/psdl.txt 
file /caps/prototypes/graph.pic 
file /caps/prototypes/graph.links 
file /caps/prototypes/psdl.ds 
files /caps/prototypes/NewNode. XX 


HK KKK KKK KEK KK KEKE KKK KKK KEKE KK KEK KKK KEKE KEK KK ER KKK KKK KEKE KEKKEKEKKEKKEKKKKKKKKKK / 


{ 


char editor; 
char carriage return; 


int 


construct done = 0; 


while(!construct_done) { 


system("clear") ; 


fprintf(stdout, "\n\n\n\n CONSTRUCT MODE\n\n") ; 
fprintf(stdout," (g) raphic editor\n"); 
fprintf(stdout," (s)yntax directed editor\n"); 
fprintf(stdout," (r)eturn to main menu\n"); 
fprintf(stdout, "\n Select Option: "); 


fscanf (stdin, "$c", &editor) ; 
fscanf (stdin, "%c", &carriage return); 
switch(editor) { 
case ‘’g’: 
system("clear") ; 
if (fork() == 0) { 
code=execl (SHELL, SHELL, "-£",GRAPHIC_ EDITOR, 0) ; 
exit (code) ; 
} 
wait (&status) ; 
break; 
case ’3'; 
syntax editor (); 
break; 
case ‘r’;: 
construct _donett; 
break; 
default: 
fprintf(stdout, "\n Invalid Choice\n") ; 
sleep (3); 
break; 
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int execute () 
[ICRI GIGI III II III IIA AIK 


Function: execute selection from caps main menu 
Date: 29 Dec 89 

Called By: main () 

Calls: program /caps/translator/translator 


program /caps/static scheduler/pre_ ss 
program /caps/static_scheduler/static_ scheduler 
program /caps/dynamic_scheduler/dynamic_ scheduler 
Side Effects: file /caps/prototypes/psdl tl.a 
file /caps/prototypes/operator.info 
file /caps/prototypes/ss.a 
file /caps/prototypes/non crits 
file /caps/prototypes/ds.a 
KAKA KKK KK KKK IK RK KKK KKK KK KKK IKK KKK KKK KKK KKKKKKEKEKKKKKKKKKKKKKKKKKKKKK KK KK / 


{ 
char hostname [32]; 
int check_prototype; 


system("clear") ; 


/* check for source file from the graphic editor or syntax directed 
editor which represents current prototype design */ 
if ((check prototype = open(TEXT_FILE, O_RDONLY,0)) == -1) { 
fprintf (stdout,"\nNo Completed Prototype Available\n") ; 
sleep (3); 
return Q; 
} : 
close (check prototype) ; 


fprintf(stdout, "\nTranslating ...\n"); 
if (fork() == 0) { 
code=execl (TRANSLATOR, TRANSLATOR, TEXT FILE, "-o", 
PSDL TL HOME, 0); 
exit (code); 
} 
wait (&status) ; 


fprintf(stdout, "\nBuilding Static Schedule ...\n"); 
if (fork() == 0) { 
code=execl (PRE SS, PRE SS, TEXT FILE, "-o", 
PSDL COMPOSITES, 0); 
exit (code) ; 
} : 


wait (&status) ; 


if (fork() == 0) { 
coderexecl (STATIC, STATIC, 0); 
exit (code); 


} 


wait (&status) ; 
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fprintf(stdout, "\nBuilding Dynamic Schedule ...\n"); 
if (fork() == 0) { 

code=execl (DYNAMIC, DYNAMIC, 0); 

exit (code); 
} 


wait (&status); 


system(MV_TL_ WORK) ; 
system (MV_DS_ WORK) ; 
system (MV_SS_ WORK) ; 


gethostname (hostname, sizeof (hostname) ) ; 
if (!strcmp (hostname, SERVER)) { 
if (fork() == 0) { 
code=execl (ADA COMPILER, ADA_COMPILER, 
“static “schedulét, Y-£Y,*Ptliat, t*ds.a", "ss.a", 
"~o", PROTOTYPE, 0); 
exit (code) ; 


) 
else { 
if (fork() == 0) { 
code=execl(R_ SHELL, R_SHELL, SERVER, "a.make", 
"static schedule®, 3-£*%, %tl-at, “ds.a",-"se.a", 
"-o", PROTOTYPE, 0); 
exit (code) ; 
) 
) 
fprintf(stdout, "\nCompiling ...\n"); 
wait (&status) ; 


system(MV_TL_ HOME) ; 
system(MV_DS_ HOME) ; 
system (MV_SS_ HOME) ; 


/* execute */ 
signal (SIGINT, SIG_IGN); 
fprintf(stdout, "\nExecuting ...\n"); 
sleep (1); 
system("clear") ; 
if (fork() == 0) { 
signal (SIGINT, SIG_DFL); 
code=execl (PROTOTYPE, PROTOTYPE, 0); 
exit (code) ; 
} 
wait (&4status) ; 
fprintf(stdout, "\nExecution Completed\n") ; 
sleep (3) ; 
Signal (SIGINT,SIG DFL); 
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int modify () ) 
[RRR KKKKK ER KRRRERERKRREKKEKEKKRK KKK KKRKRAKRKKKRKARKKRRARAX AA 


Function: modify selection from caps main menu 
Date: 6 May 89 

Called By: main () 

Calls: none 

Side Effects: none 


KHKAKKKKKKKKKRAKEREAEKEKEKKKKRKKKKREKKKKAKKKKREKKREAKEKKKRKKRKEARKKKKKRAKKKKKREARAT 


{ 


fprintf(stdout, "\n Modifications in progress\n"); 
sleep (3); 
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int syntax editor () 
[BR RIK I KK KK IK IK IKK IK IK IKK IK IK IK IKK IK IK IK IK TOK TOK IK ICT SOK ICR IK TOK TORK KOK SOK IK SOK IK BOK 


Function: syntax directed editor option from construct submenu 
Date: 6 May 89 

Called By: construct () 

Calls: none 

Side Effects: file /caps/prototypes/psdl.txt 


SR RAK KKAKAKAKKKKEK KKK KKK KK KKK KKK KKK KEKE KKK KKK K KKKKEKKKKKREKKEREKREREKEKEKKARKE | 
char text; 
char hostname [32]; 
char carriage return; 


system("clear") ; 


fprintf(stdout, "\n\n\n SYNTAX DIRECTED EDITOR\n\n\n") ; 
fprintf(stdout," Do you desire instructions\n") ; 
fprintf(stdout," (y)es\n"); 

fprintf(stdout," (n)o\n") ; 

fprintf(stdout, "\n") ; 

fprintf(stdout, " Select Option: "); 


fscanf (stdin, "%c", &text) ; 
fscanf (stdin, "$c", &carriage return) ; 
if (text == ‘’y’) { 

system("clear") ; 

gethostname (hostname, sizeof (hostname) ) ; 

if (!strcemp (hostname, SERVER) ) 

system(LOCAL MANUAL) ; 
else 
system(REMOTE MANUAL) ; 
} 
if (text = ‘/y’) { 
fprintf(stdout,"\n\nPress Carriage Return to Continue ;: "); 
fscanf (stdin, "%c", &carriage return); 

} 
system("clear") ; 
if (fork() == 0) { 

code=execl (SDE, SDE, 0); 

exit (code); 
} 
wait (&status) ; 
system("mv psdl.txt /n/suns2/work/caps/prototypes") ; 
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APPENDIX C SHELL SCRIPT FOR GRAPHIC EDITOR 


# File: ge 

# Purpose: shell to run the graphic editor - directs input and output 
# Author: laura j. white 

# Date: 17 dec 1989 


/n/suns2/work/caps/graphic_editor/graph 

/n/suns2/work/caps/graphic editor/nodes < /n/suns2/work/caps/prototypes\ 
/graph.links 

cat /n/suns2/work/caps/prototypes/graph.links /n/suns2/work/caps\ 
/prototypes/psdl.ds >> /n/suns2/work/caps/prototypes/psdl.imp 
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APPENDIX D GRAPHIC EDITOR 


| % HH He He He Ke HK HK He Ke HICK HC Ke He He eH He Ke He HCH HH HH IK IKK IK HHH IKK KK KKK IK KKK IK HKKEKKKKEKKKK KKK K KKK 


PROGRAM: GRAPH.C 

AUTHORS : ROGER K. THORSTEN 
LAURA J. WHITE 

DATE: 10 November 1988 


KHKKKKKKKKKKIKK KKK KKKEKKKKKKK KK KKK KER EKKKKKKKKKKKKKKKRIEKKKKKKKKKKKEEKKEKKEKKKKK / 


/* compile this program with "makid graph.c" */ 

#ifdef MAKID 

static char 

*makid[{]) = { 

"@(M)cc -g graph.c -o graph -lm -lsuntool -lsunwindow -lpixrect" 
); 

#endif 


<stdio.h> 
<suntool/sunview.h> 
<suntool/canvas.h> 
<suntool/panel.h> 
<suntool/seln.h> 
<math.h> 

<string.h> 
<ctype.h> 


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


/* system dependent names */ 


#define ICON "/n/suns2/work/caps/graphic_editor/editor.icon" 
#define PRINT "screendump | rsh virgo lpr -Pssl -v " 

#define SERVER1 "virgo" 

#define SERVER2 "suns2" 

#define SERVER3 "libra" 

#define SERVER4 "taurus" 


/* define constants for the editing modes */ 


#define 
#define 
#define 
#define 
#define 
#define 


OPERATOR 
DATA_FLOW 
SELF LOOP 
INPUT 
OUTPUT 
EXTERNAL 


OM & WHF © 


#define PI 3.141592654 


#define 
#define 


DISP WIDTH 142 
DISP_HT 55 
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/* the display width */ 
/* the display height */ 


#define ARROW_LENGTH 9 /* length of the arrow head * 
#define TEXT MAX LEN 35 /* length of name which is visible 
#define TIME MAX LEN 10 /* length of the time which is visible * 


#define PROXIMITY 25 
/* import predefined editor icon * 


static short editor icon[] = { 
#include ICON 
}; 


DEFINE ICON_FROM IMAGE (editor, editor icon); 


Frame frame; /* define the handle for the frame * 
Panel mouse panel, /* defines the handle for the mouse interface panel * 
op_mode panel, /* define the handle for the op mode selection panel * 
edit mode panel, /* define the handle for the side panel * 
time panel, /* define the handle for the time panel 4 
name_panel, /*x define the handle for the name reading panel * 
message panel; /* define the handle for the message panel*/ 
Canvas drawing canvas; /* define the handle for the drawing canvas * 
Event *event; /* define the handle for events *% 
Pixfont *bold; /* define the handle for the borders *% 
Pixwin *drawing pw; /*x define the handle for the drawing pixwin 
int server = 0; /* gloabal - flag for server/diskless sun ’ 
int edit mode; /* global - stores the current edit mode # 
int name_checked = 0, /* global - signals that name is valid ’? 
time_checked = 0; /* global - signals that time is valid ? 
int graph_saved = 0; /* global - signals whether or not 


the graph has been saved ? 


Panel item object_name, /* handle for the name ? 
message, /* handle for the msg 3 
time constraint; /* handle for the time ? 
char *tmp buf, /* global - buffer to read the name into # 
*tmp bufl; /* global - buffer to read the time constraint into ? 

FILE pln ae /* define the PSDL link statement file * 
key 
°F 


typedef struct { ) 
int length; /* the number of characters in the name ! 
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char string[80); /* array to hold the name or time string */ 
}Name, Time; 


typedef struct line{ /* stores output and data flow lines */ 
Name *name; /* name of line */ 
int lntype; /* identifies the type of line it is */ 
int xstart; /* the x coord of the lines starting posit */ 
int ystart; /* the y coord of the lines starting posit */ 
int xstop; /* x coord of its stopping posit */ 
int ystop; /* y coord of its stopping posit */ 
Name ‘*dest; /* operator that the line terminates at */ 
struct line *next; /* pointer to the next line from this operator */ 

} Line; 

typedef struct operator { /* storage stucture for the operators and inputs */ 
Name *name; /* operator’s name */ 
int optype; /* identifies contents as an operator or external */ 
int xstart; /* x coord where operator should start to be drawn */ 
int ystart; /* y coord where operator should start to be drawn */ 
int xstop; /* x coord of the operator’s opposite corner */ 
int ystop; /* y coord of the operator’s opposite corner */ 
Time *time_const; /* maximum execution time for the operator */ 
Line *head; /* head of the operator’s output list */ 
Line *tail; /* tail of the operator’s output list */ 
struct operator *next; /* pointer to next operator in list */ 

}Operator; 

typedef struct { /* the list for operators and inputs */ 
Operator *head; /* pointer to the head of the list */ 
Operator *tail; /* pointer to the tail of the list */ 


}Operator list; 


Operator list operator list; 
Operator list *op list = Soperator list; 


Operator *op, *sop, *dop; 

Name name_pointer; 

Name *name = &name_pointer; 
Time *to; 

Line *1n; 


/* forward declarations of functions */ 
static Notify value process canvas _events(); 
static Notify value mode_select(); 


Operator *alloc_ operator (); 
Operator *pick operator (); 
Operator *create_op(); 
Line *alloc line(); 


Line *pick_line (); 
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Line 


Name 
Name 


Time 


int 
int 
int 
int 


int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 
int 


*create line(); 


*external (); 
*get_ name (); 


*get_time_ const (); 


is op pick(); 

is line pick(); 

is valid ada _id(); 
is_valid_time_const(); 


append to op list () 
get_hostname () ; 

quit _proc(); 

load _proc(); 

dump screen(); 
search (); 

compose (); 
decompose () ; 

store proc(); 

out _of mem(); 

input text (); 

input _time(); 
append line to op(); 
13 Opepick(); 

is input _pick(); 
process operator (); 
process line(); 
rubber band(); 
redraw diagram() ; 
delete line(); 
delete _op(); 
delete input lines(); 
display error _msg(); 
display name (); 
display tc(); 
draw_arrowhead(); 
draw object (); 
create PSDL(); 

store diagram(); 
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mMain(argc, argv) 


int argc; 
char **argv; 


[RR KR I KK I IKK II IKK III I IIR I IIR III IKK IKK I IORI IK ITOK IKI I ITOK II KIKI KK IKK KIA KKK KICK 


function: Sets up graphic editor 
called by: CAPS User Interface 
calls: create mouse panel () 


create operating mode panel () 
create editing mode panel () 
create name panel () 
create time panel () 

create message panel () 


a NA RANEAAARAAKAAKARAKAKAKEAAKKERAKREKKKKKKKEKKKKEKEKKKEKKEKEKKEKKKEKKKKEKKREKKKKE / 


{ 


get_hostname () ; 


/* cause borders to highlight if region entered */ 
bold = pf open("/usr/lib/fonts/fixedwidthfonts/screen.b.12") ; 
1£ (bold == NULL) exit (1); 


/* create the outer display frame */ 
frame = window _create (NULL, FRAME, 


FRAME LABEL, "CAPS - GRAPHIC EDITOR", 
FRAME ICON, &editor, 

FRAME ARGS, argc, argv, 

WIN ERROR MSG, "can’t create window.", 
WIN X, 25 

WIN XY, 1, 

WIN_ROWS, DISP_HT, 

WIN COLUMNS, DISP_ WIDTH, 

0); 


/* create mouse panel */ 
mouse panel = window create(frame, PANEL, WIN _FONT , bold, 0); 
create mouse _ panel (); 


/* create op_mode_panel */ 
op_mode panel = window create(frame, PANEL, WIN FONT , bold, 0); 
create operating mode panel(); 


/* create editing mode panel */ 
edit_mode panel = window _create (frame, PANEL, WIN _FONT, bold, 0); 
create editing mode panel (); 


/* create panel to read object names */ 
name panel = window_create(frame, PANEL, WIN FONT, bold, 0); 
create name panel (); 


/* create panel to read operator time constraints */ 


time panel = window create(frame, PANEL, WIN_FONT, bold, 0); 
create time panel (); 
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/* create message panel */ 
message panel = window_create(frame, PANEL, WIN FONT, bold, 0); 


create message panel (); 


/* create canvas to draw on */ 

drawing canvas = window_create(frame, CANVAS, WIN FONT, bold, 
WIN CONSUME _KBD_EVENT, WIN ASCII EVENTS, 
WIN EVENT PROC, process _ canvas events, 
CANVAS RETAINED , TRUE, QO); 


/* cause drag events to be accepted */ 
window _set (drawing canvas,WIN CONSUME PICK _EVENT, LOC_DRAG, 0); 


drawing pw = canvas pixwin(drawing canvas) ; 


/* initialize the operator list */ 
operator list.head = operator _list.tail = NULL; 


/* poll for events in the frame */ 
window main _loop(frame) ; 
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get hostname () 
[RRR KEKE KEKE KKK K KKK KKK KK KKK KKKKKRKKKEKKEKK KKK KKK KKK KKKEK KKK KEKRRERKKKEEKEEEKKEEKK 


function: This function determines if the user is using a sun server. 
The screendump capability for the graphic editor is only functional 
if the editor is operating on a sun server. The control. panel 
button and registration of the dump screen function are not 
part of the graphic display if using a diskless workstation. 

called by: main() 

calls: none 


He KI KI KKK II KIRK KKK KKH RRR KKK KKK ERE REE KK KKK KEKE KKK KK KKK KKKK KEK / 


{ 


char hostname [32]; 


gethostname (hostname, sizeof (hostname) ) ; 

if (!strcmp (hostname, SERVER1) ) 
servertt; 

if (!strcmp (hostname, SERVERZ2) ) 
servertt; 

if ('strcmp (hostname, SERVER3) ) 
server++; 

if ('strcmp (hostname, SERVER§4) ) 
servertt; 
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create mouse panel () 
[RMEKKKKKEKKKKKEKEEKKKEKKKK RR KK KKEKKKEKKKEKKKKKEKEKKKKKRKRKKK K RE K A ee 


function: 


describe the functionality of the mouse buttons 


called by: main () 
calls: none 


Draws the mouse interface panel which contains messages which 


Hom AK KKH KK KK KKK KKK KKK KKK KKK KKK KKK KKK KKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKAKE 


{ 


/* display panel messages */ 
panel create item(mouse_ panel, PANEL MESSAGE, PANEL LABEL STRING, 
" MOUSE INTERFACE:", 0); 


panel create_item(mouse_ panel, PANEL MESSAGE, PANEL LABEL STRING, 
Ww ww 0) ° 
tf ? 


panel create_item(mouse_ panel, PANEL MESSAGE, PANEL LABEL STRING, 
w La | 0) e 
v ¢ 


panel create _item(mouse_panel, PANEL MESSAGE, PANEL LABEL STRING, 
, Left Mouse SELECTS graphic editor functions and", Q); 


panel create _item(mouse_panel, PANEL MESSAGE, PANEL LABEL STRING, 
"locations for new graphic objects", 0); 


panel _create_item(mouse_panel, PANEL MESSAGE, PANEL_LABEL STRING, 
wT w 0) ° 
v ’ 


panel create _item(mouse_ panel, PANEL MESSAGE, PANEL LABEL STRING, 
" Middle Mouse MOVES graphic objects", 0); 


panel create_item(mouse_ panel, PANEL MESSAGE, PANEL LABEL STRING, 
ww " 0 ) ° 
g e 


panel_create _item(mouse_ panel, PANEL MESSAGE, PANEL LABEL STRING, 
La La 0) ° 
f v 


panel _create_item(mouse_panel, PANEL MESSAGE, PANEL LABEL STRING, 
a Right Mouse DELETES when positioned:", 0); 


panel _ create_item(mouse_panel, PANEL MESSAGE, PANEL LABEL STRING, 
"within an operator, on the tail of a self loop,", 0); 


panel create_item(mouse_panel, PANEL MESSAGE, PANEL_LABEL STRING, 
"on the tail/head of a data flow, input or output", 0); 


/* fit border around the mouse panel */ 
window _fit_ height (mouse_panel) ; 
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| 





create operating mode panel () 
[ & eH HK KKK KK KK HK KK He He He HK KK I KI IK IK IK I IK III K IF III IOI IF II ICICI IK IK ICSI I SOK IAAI TOK Ste 


function: This procedure builds the operating mode panel for the graphic 


editor, which consists of the buttons : "print Display” (if using 
a server), "Load Existing", "Store", and "Quit". 


called by: main() 
calls: none 


FOI IOI I IOI I III OS IIIA I Kt] 


{ 


/* display panel message */ 
panel_create_item(op_mode panel, PANEL MESSAGE, 
PANEL LABEL STRING," OPERATING MODE:", 0); 


/* create button to permit a screendump of display */ 
if (server) { 
panel _create_item(op_mode panel, PANEL BUTTON, 
PANEL LABEL IMAGE, 
panel button image(op mode panel, "Print Design", 0, 0), 
PANEL NOTIFY PROC, dump _ screen, 0); 


/* create button to cause data to be read from the data base */ 
panel create _item(op_ mode panel, PANEL BUTTON, 
PANEL LABEL IMAGE, 
panel button_image(op_mode panel, "Load Existing", 0, 0), 
PANEL NOTIFY PROC, load_proc, Q); 


/* create button to interface with databases */ 

panel create_item(op_mode_ panel, PANEL BUTTON, 
PANEL LABEL IMAGE, 
panel button_image(op_ mode panel, "Search", 0, 0), 
PANEL NOTIFY PROC, search, 0); 


/* create button to compose design*/ 

panel create item(op_mode_panel, PANEL BUTTON, 
PANEL LABEL IMAGE, 
panel button_image(op_mode_panel, "Compose", 0, 0), 
PANEL NOTIFY PROC, compose, 0); 


/* create button to decompose design*/ 

panel create item(op mode panel, PANEL BUTTON, 
PANEL LABEL IMAGE, 
panel button_image(op_mode_panel, "Decompose", 0, 0), 
PANEL NOTIFY PROC, decompose, 0); 


/* create button to store the diagram in the data base */ 

panel create item(op_mode_panel, PANEL BUTTON, 
PANEL LABEL IMAGE, panel_button_image(op_mode_panel, "Store", 0, 0), 
PANEL NOTIFY _PROC, store proc, 0); 
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/* create button to terminate the program */ 

panel create item(op mode panel, PANEL BUTTON, 
PANEL LABEL IMAGE, panel button_image(op mode panel, 
PANEL NOTIFY PROC, quit proc, 0); 


/* fit border around the top panel */ 
window fit height (op _mode_ panel); 
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wOuLt 


0, 


0), 


create editing mode _ panel () 
[RRR ROI III OOOO OOOO III OIRO ITO TOO ITO I AIK 


function: builds the editing mode panel for the graphic 


editor 
called by: main() 
calls: none 


kakkkkkkkkk ki kkkh kkk kk kkikk kk kk kkk kk kaki ki kkk hhkhkhkkkkkkk kkk hhh kkk kkk / 
{ 

/* create the mode select panel */ 

panel create_item(edit_mode_panel, PANEL CHOICE, 


PANEL LABEL STRING, " EDITING MODE: 7 

PANEL CHOICE STRINGS, . Draw Operator "; 
be Draw Data Flow S. 
Draw Self Loop ?, 
r Draw Input 7 
" Draw Output — 
0, 

PANEL FEEDBACK, PANEL INVERTED, 

PANEL NOTIFY PROC, mode _ select, 0); 


/* fit window around the editing mode panel */ 
window fit height (edit_mode_panel); 


147 


create name panel () 
[RK KKK KR RK KKK KKK KK RK KICK KK KKK KK KKK IKE KK IK IK KICK KIKKEKKKKAKKKKKKK KA KKK KKK KK KKK 
function: builds the identifier name panel for the graphic editor 

called by: main() 

calls: none 

KKK HK HK KKK KKK HK KKK KKK KKK KKK KK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KK KKK KKKKKKKKKKKK KK: 


{ 


object _name = panel create _item(name_ panel, PANEL TEXT, 


PANEL LABEL STRING, " IDENTIFIER NAME:", 
PANEL VALUE, nn 

PANEL VALUE_DISPLAY_LENGTH, TEXT MAX LEN, 

0); 


panel create item(name panel, PANEL BUTTON, 
PANEL LABEL IMAGE, panel _button_image (name panel, "Read Name", 0,0), 
PANEL NOTIFY PROC, input text, 
0); 


window fit height (name_panel) ; 


148 | 


create time panel () 
A AAAKAAAAALAKKEKRAKAKAAKAKAAKKKKKKKKKKKKAKKEKKKKEKEKRKRKEKKKKKKKKKKKKKKKKKKKKEKEK 


function: builds the time constraint panel for the graphic editor 
called by: main() 


calls: none 


Be He HK He HHH KI HH IH KIKI KI KKH KKK KKK KKK KEK KKK KKK KKKEKKEKEKKEKKEKEKKKKKKKKKKK KKK / 


{ 


time constraint = panel _create_item(time_ panel, PANEL_TEXT, 


PANEL _LABEL_ STRING, " TIME CONSTRAINT:", 
PANEL VALUE, nn 

PANEL VALUE _DISPLAY_LENGTH, TIME MAX LEN, 

0); 


panel create_item(time_panel, PANEL MESSAGE, 
PANEL LABEL STRING, " i 
0); 


panel create_item(time_panel, PANEL BUTTON, 


PANEL LABEL IMAGE, panel button_image(time_panel, "Read Time", 0,0), 
PANEL NOTIFY PROC, input_time, 
0); 


window fit height (time_panel); 
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create message panel () 

[RRR RRERKKER EKER KK KK RE KKK ERK KKK KKK KER KKK KER KEKEKKEKKKKKEKKKKRKKKKKKKKKKKKKKK KK KT 
function: builds message panel for editor error messages to the user 
called by: main() 

Cals. none 
KKK KKKKKKEKKRKK KEKE KKK KK KRKEKRKEK KKK KEK KKK KKK KKK KKK KIRKE KAKKKKKKKKKRKKKK KKK KKK KKK: 
{ 
/* display messages panel label*/ 
message=panel create item(message_ panel, PANEL MESSAGE, 
PANEL LABEL STRING, 
" MESSAGE PANEL:", 0); 


window fit height (message panel); 
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static Notify value 
mode select (item, value, event) 
Panel item item; 
int value; 
Event *event; 
[RRR KKKKKKKAKKEKEAKKKKEKKKKKKKKKKKKKKKRREREKKKEKKREKKREKKKKKKKEREKRKEKKKEERKKKRKEKREREKEKE 
function: sets the mode that the editor is operating in by setting the 
global variable "edit mode” to one of the predefined mode constants 
called by: notifier 
calls: none 
He He He te te te He te te KK IKI I I IK IKI IK II III III III IKI KI IK KKK III III III IKI KAKI IKKKKKIIAA AKI | 


{ 
switch(value) { 
case OPERATOR: 


edit mode = OPERATOR; 
break; 
case DATA_FLOW: 
edit mode = DATA_FLOW; 
break; 
case SELF LOOP: 
edit _mode = SELF_LOOP; 
break; 
case INPUT: 
edit mode = INPUT; 
break; 
case OUTPUT: 
edit mode = OUTPUT; 
break; 
default: 
break; 
} 
return; 
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quit iproe() 
[RRR KKK KKK KKK IK KK IKK KK KK KKK KK KKK KKK KK KKK KKK KKK KK KKK KKK KKK KKK KKKK RE 
function: sets the mode that the editor is operating in by setting the 
global variable “edit mode" to one of the predefined mode constai 
called by: notifier 
calls: display error msg() 
RRR KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK AKK KAKA KKAKKKKKKKKKKKKKKKKKKKKKKKKKKKERE: 


{ 

if (graph saved) { 
window set (frame, FRAME NO CONFIRM, TRUE, 0); 
window destroy (frame) ; 

} 

else { 
display error msg(6); 
window set (frame, 0); 
window destroy (frame) ; 
display error msg(1l); 
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load proc() 


[RRR KREKKK KEKE KKK KKR KKK KKK KK KEKE KEKE KEKE KKEKKKKEIA KKK KEKE KKEKEEEKEKEKKEKKKKKKKK KK KEK 


function: This function causes a previously drawn and stored diagram to 
be loaded when the load _ existing button is selected. 
called by: notifier 
calls: create op() 
append to_op list ()} 
create line() 
append line _to_op(} 
KHKKKKKKKKKKKKKIKKEK KEK KEK KKK KKK KKK KKK E KK EEK KEKEKKEKKKRKKKEKKEKKKKKKKKKKKKKKKKEKK / 


{ 
int optype,xl,y1,x2,y2; 
Name *oname, 
*dest; 
Time *tc; 


graph_saved = 0; 
g = fopen("/n/suns2/work/caps/prototypes/graph.pic", "r"}; 


while (!feof(g)})) { 
oname = (Name *}malloc (sizeof (Name) ) ; 
fscanf (g, "%d\n", &0ptype) ; 
fscanf (g, "’d\n", &x1} ; 
fscanf (g, "d\n", &yl) ; 
fscanf (g, "d\n", &x2); 
fscanf (g, "d\n", &y2) ; 
fscanf (g, "s\n", oname->string} ; 
oname->length = strlen (oname->string) ; 
if ((optype == OPERATOR) ||! (optype == EXTERNAL}) { 
te = (Time *}malloc(sizeof (Time) ); 
fscanf (g, "%s\n",tc~->string) ; 
tce->length = strlen (tc->string) ; 
op = create op (oname, optype,xl,yl,x2,y2,tc}; 
append to op list (op_list,op}; 
} 
else { 
dest = (Name *})malloc(sizeof (Name) }; 
fscanf (g,"%s\n", dest->string} ; 
dest->length = strlen (dest->string) ; 
dop = create _op(dest,optype,xl,y1,x2,y2,tc); 
ln = create_line (oname, optype,x1,y1l,x2,y2,dop) ; 
append line _to_op(op, ln); 
} 
} 
fclose(g); 
redraw_diagram(); 
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dump screen () 

[REAR IKIKKEKR I KKK KK KK KKKERKEKKEKKKEKRKKKRKKRKKKRKREAKKRKEK EKER KKH 6X KA 
function: performs a screen dump of the graphic editor display. 

called by: notifier 


calls: none 
FoI II HAH IIA AIHA IKI IKI IIH IKK IKK KI K KKK KK KKK HKKK KKK KKK KKK KKK KKKKKKKKE: 


{ 
system (PRINT) ; 


search () 

[RK KKK KKK KK KK KKK KKK KKK KKK KKK KKK KKK KKK KKK IKK K KKK IKK EKER HK KKK KKKKKEKKKK KKK 

function: will interface with the CAPS database manager when the search 
button is selected 

called by: notifier 

calls: none 

KKK IAI K IKK IK AK AKA KKK K KEKE KKK AKHEKKKKEKKKKKKKKEKKKKKKKKKKKKKKKKKHKKKKKKKKKE 

{ 

) 


compose () 

[RRR IK IKI K KK IKK KKK KK KKK KKK KKK KKK KKK KKK KKK KK KK KK KKK KKK KKK KKAKKKKKKKK KKK 

function: will perform the composition of a decomposed design when the 
compose button is selected 

called by: notifier 


calls: none 


KHKKKKHKKKKKKKKKKKKEKEKEKKKKKEKEKEKKEKKKKKHKKKKKKEKEKKKEKKKKKKKKKKKEEKKKKKKKKKKKKKKKKKK 


{ | 
} 


: 

| 

: 

decompose () | 

[RAHKKKEKEKKEREERERREE ERR ERERRERERRERRERERREERRRRKE KERR KKK K KKK AHH HR 

function: will perform the composition of a decomposed design when the 
compose button is selected 

called by: notifier 

calls: none 

KHK IKI KK KK KKK KK KI KKK KKK HI K KKK KKK KIKI KKK IKI KKK KKK AKI HKKKHKKHKKKKKKKKKHKKKKKKKKKS 


| 
| 
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store proc () 
ieee A AAR EA RA RAK KAKA KKKARARERKAKKRERKERKKERKKREKREKKARKKAKAKK BARK SRK 
function: stores the data flow diargam into the design data base. 
Prior to storing the diagram it calls “create _ PSDL" which 
transforms the picture into its equivalent PSDL statements. 
called by: notifier 
calls: create PSDL() 
store diagram() 
PAK KKK KKK IAI IKK KKK IIIA KA K KK AK KKK KEKE AKKKKKKEKKAKAKKKKKKKKAKKKKKKKKKKKKK KK KKK KI / 


{ 
create PSDL(); 


store _diagram(); 
graph_ saved = 1; 
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static Notify value 
process canvas events (canvas, event) 
Canvas canvas; 


BEBvent *event; 
[RRR KKEHK KEKE KKK KKK KKK KEE KERR KKK KKK EKKEKKRKKEKEKEREKEKKEKKKKKKKK KKK A 


function: draws the graphical objects. 
called by: notifier 


calls: 


pick line () 
delete line () 
pick operator () 
detetvemer 
rubber band () 
process object () 
redraw diagram () 


KIKI IKKIKKK KKK KKK KKEKKKKKEKKKKKKKKKKKKKKKKKKKKK KK KKK KKKKRKRKKKKRK KKK: 


{ 


int id = event _id(event); 
Static Antist, 7yi7 2, v2, 
static int new_posit = 1; 
static int left_button = 0; 
static int middle button = 0; 
Operator *op; 

Line *ln; 


if (event_is_ button(event)) { 


if (event_is_down(event)) { /* 
xi = eventex (event, 
yl = event_y (event); 
switch(id) { 
case MS LEFT: 
new posit =1; 
x2 = x1; 
y2 = yl; 
lefe buttonm=t, 
break; 
case MS MIDDLE: 
break; 
case MS RIGHT: 


/* check for button events: 


store location where button goes down 
/* position of button down event: 


/* create new object 


/* pick object for moving: 


/* pick object for deletion’ 


if ((1ln = pick _line(op list,x1,y1)) != NULL) { 


op = NULL; 


delete Tine(epels st, cp, in). 


} 


else 


if ((op = pick_operator (op list,x1l,y1)) != NULL) 
delete op(op_ list,op); 


redraw diagram(); 
break; 


} 


else if (event_is up(event)) { 
Switch (id) { 
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ee Ss 


case MS_ LEFT: 
rubber band(x1l,yl1,x2,y2); 
x2 = event x(event); 
y2 = event _y (event); 
process object (xl,yl,x2,y2) ; 
redraw diagram() ; 
left _button=0; 
break; 
case MS MIDDLE: /* stubbed */ 
if (!middle_ button) 
break; 
case MS_ RIGHT: /* stubbed */ 
break; 


} 
else 
if (id LOC DRAG) { 
if (left button) { 
if (!new posit) { 
/* rubber band operator’s boundary while being drawn */ 
rubber _band(xl,y1,x2,y2) ; 
x2 = event x(event) ; 
y2 = event_y (event) ; 
rubber band (xl,yl,x2,y2); 
} 
else 
new posit = 0; 


return; 
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process object (xl,y1,x2,y2) 
int xl yl, s2ye, 


[RRR KKK KR RRR RRR RRR RRR KKK KKK KKK KKK KKK RK KK IKK KK KK EKER IKKE KK KKK KKK KKK KKK KKK AK 


function: 
called by: 
calls: 


processes operators, data flows, self loops, inputs and outputs ~ 
process canvas events () | 
pick _ operator () 

process operator () 

process line() 


display error msg() 


KREKKKKKKEKKKEKEKKEKEKKEKEKKEKRKEKKEKKEKEKKKEKEKKEEKEKRKKKKKKKKKEKEKKKEKKKKKKEKEKKEKKKEKKKKKEKKKKEKEKE: 


{ 


Operator *op, *sop, *dop; 


switch (edit_mode) { 
case OPERATOR: 


if (nmame_checked && time _ checked) { 


/* draw object if it is not positioned on top of an existing object! 


if (((pick_operator(op list,xl,yl))==NULL) && 
((pick_operator (op list,x2,y2))==NULL)) { 
process operator (OPERATOR, x1,yl1,x2,y2) ; 


} 

elsert 
display error msg(4); 

} 


break; 


case DATA FLOW: 


if (name_checked) { 
/* check if the line starts and terminates on an operator */ 
if (((sop=pick_ operator (op list,xl,yl))!=NULL) && 
((dop=pick operator (op list,x2,y2))!=NULL) && (sop != dop) 
process line (DATA FLOW, x1,y1,x2,y2,sop,dop) ; 


} 

elsem 
display error msg(5); 

} 


break; 


case SELF LOOP: 


if (name checked) { 
/* draw the loop if it starts on an object and is not */ 
/* intersecting an existing object */ 
if (((sop=pick operator(op list,xl,yl))!=NULL) && 
((dop=pick operator(op list,x2,y2))==NULL)) { 
process line (SELF LOOP, x1, y1,x2,y2,sop, sop); 


} 

else { 
display error msg(5); 

} 


break; 
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case INPUT: 
if (name_checked) { 
/* check if line ends on an operator */ 


if (((sop=pick_operator(op_list,xl,yl))==NULL) && 
((dop=pick_operator(op_list,x2,y2))!=NULL)) ( 
process line (INPUT,xl,yl,x2,y2, sop, dop) ; 


} 
else ( 
display error _msg(5); 
} 
break; 
case OUTPUT: 
if (name_checked) ( 
dop = NULL; 
/* check if line is valid */ 
if (((sop=pick_operator (op list,xl,yl))!=NULL) && 
((dop=pick_operator (op_list,x2,y2))==NULL)) ( 
process line (OUTPUT, xl, y1,x2,y2, sop, dop) ; 


} 
else { 
display error _msg(5); 


} 

break; 
default: 

break; 
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draw object (otype,x1l,y1l,x2,y2) 
int otype, xl, yl,x2, y2. 


[RRR KKK IKK KKK KK KKK KKK KK KKK KKK KKK KKK KEK KK KKK KK KK KK ERE KKKEKKKKKKEKKKKKAKK / 


function: 
called by: 


calls: 


draws object in the drawing space 
process operator () 

process line () 

redraw diagram() 

none 


[RRR KR KKK KKK KK RK KKK KKK KKK IKK IKK KK KKK KEK KEK KE KARE KKKEKKKKKAKKAK KKK KKK KKK / 


{ 


float i,xmid, ymid, xcent, ycent; 
int xnew, ynew, xold, yold; 


switch(otype) { 
case OPERATOR: 


xmid = (x2-x1)/2.0; 
ymid = (y2-yl)/2.0; /* objects center point on the screen * 
xcent = xl + xmid; 
ycent = yl + ymid; /* find position to start drawing the object * 
xold = x2; 
yold = ycent; 
/* loop to draw the object */ 
for(i = 0.0; i <= 2 * PI; i = i + PI / 12) { 
xnew = xcent + (xmid * cos(i)); 
ynew = ycent + (ymid * sin(i)); 
pw_vector (drawing pw, xold, yold, xnew, ynew, PIX_SRC, 1); 
xold = xnew; 
yold = ynew; 





} 


break; 


case DATA_FLOW: 


pw_vector (drawing pw, xl, yl, x2, y2, PIX_SRC, 1); 
break; 


case SELF_LOOP: 


pw_vector (drawing pw, x2, yl, x2, y2, PIX_SRC, 1); 
pw_vector (drawing pw, x2, y2, xl, y2, PIX_SRC, 1); 
pw_vector (drawing pw, xl, y2, xl, yl, PIX_SRC, 1); 
break; 


case INPUT: 


pw_vector (drawing pw, xl, yl, x2, y2, PIX_SRC, 1); 
break; 


case OUTPUT: 


pw_vector (drawing pw, xl, yl, x2, y2, PIX_SRC, 1); 
break; 


default : , 


break; 
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rubber band (xl,y1,x2,y2) 
cate xk, yl,x2,y2; 
[RH HKKRKKK KKK KKK EK I KKK K KKK KKK KKK RR KK KKK KK KK KKK KKK KKKKKKKKKKKKKEKKEKKEKKKKK 
function: expands/shrinks selected drawing object 
called by: process canvas events () 
calls: none 
KKKKKKKKKKKKAKKKKKKKKKKKKKKKKKKKKKKKKKKaKKKKKKKKKKKaKKKKKhhK kh KhkKKKhhKKkKKKK KKK / 


{ 
switch(edit mode) { 

case OPERATOR: 
pw_vector(drawing pw, xl, yl, x2, yl, PIX_NOT(PIX_DST), 1 
pw_vector (drawing pw, x2, yl, x2, y2, PIX_NOT(PIX_DST), 1); 
pw_vector(drawing pw, x2, y2, xl, y2, PIX_NOT(PIX_DST), 1 
pw_vector(drawing pw, xl, y2, xl, yl, PIX_NOT(PIX_DST), 1); 
break; 

case DATA FLOW: 
pw_vector (drawing pw, xl, yl, x2, y2, PIX_NOT(PIX_DST), 1); 
break; 

case SELF_LOOP: 
pw vector (drawing pw, x2, yl, x2, y2, PIX_NOT(PIX_DST), 1); 
pw vector (drawing pw, x2, y2, xl, y2, PIX_NOT(PIX_DST), 1); 
pw_vector (drawing pw, xl, y2, xl, yl, PIX_NOT(PIX_DST), 1); 
break; 7 

case INPUT: 
pw_vector (drawing pw, xl, yl, x2, y2, PIX_NOT(PIX_DST), 1); 
break; 

case OUTPUT: 
pw_vector(drawing pw, xl, yl, x2, y2, PIX_NOT(PIX_DST), 1); 
break; 

default: 
break; 
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process operator (otype,x1l,y1,x2,y2) 
int. ot ype; al, vi7aZ 2, 

[RR KKKKKKKK KKK KK KKK KKK KKK KKK KKK KKK KK KKK KKKEKKK KKK KKKKKKKKKKKKKKKKKKKKKK AK K KKK 

function: checks the name and time constraint, stores into data structure : 

called by: process_object () | 
draw object () 

calls: draw object () 
get_time_const () | 
get_name () , 
display tc() 
create_op() 
append to op list () 


KKKKKK KK KKK KKK KKK KKK KKK KK KK KKK KKK KK KK KKK KK KKK KKK KK KK KKK KK KKK KKKKHKKKKKKKKAKAKS 


{ 
Name *obj_name; 
Time *tc; 
Operator *op; 


draw object (otype,x1,yl,x2,y2) ; ) 
tcyaeget tine const (7 
obj] name = get_name(); | 
display name(obj name, otype,x1l,yl,x2,y2); 

display tc(tc,xl,yl,x2,y2); 
op = create_op(obj_ name, otype,x1l,y1l,x2,y2,tc) ; | 
append to op list (op_list,op); | 
name_checked = 0; 

time_checked = 0; 
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process line (otype,x1,y1,x2,y2, sop, dop) 
int otype,xl,yl,x2,y2; 
Operator *sop, *dop; 
[RHI KKK KKK KKK KEKE KK RK KEK KKK KKK KK KKK IKK KKK KIKI KKK IK KKK EK KKK KKK KIK KK KEKE K KKK 
function: gets attributes and draws a line 
called by: process object () 
draw object () 
calls: draw object () 
draw_arrowhead () 
get_time_const () 
external () 
create op() 
append to _op list () 
get_name () 
display name () 
create line () 
append to _ op() 


eK KH I I HI I KKK I IK KI IK HII IK KKK IKK KIKI KK KKK IKK KKK IKK KKK KK KEK KKK KEKE KK KEK KKK KKK / 


{ 
Name *obj name, *op name; 
Line *ln; 


draw object (otype,x1l,y1,x2,y2) ; 
if (otype == SELF_LOOP) 
draw_arrowhead (x2, y2,x2,y1); 
else 
draw_arrowhead (x1, y1,x2,y2); 
if (otype == INPUT) { 
tc = get _time_const(); 
op name = external (); 
sop = create_op(op_name, EXTERNAL, x1,y1,x2,y2,tc); 
append to _ op list (op_list,sop); 
} 
obj name = get_name(); 
display name (obj_name, otype,x1,y1,x2,y2) ; 
ln = create_line(obj_name,otype,x1,y1,x2,y2,dop) ; 
append line to_op(sop,1n); 
name_checked = 0; 
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Operator *create_ op(name,op type,xl,y1l,x2,y2,tc) 


[RRRKKKKKKEAK KE EKE EKER KEKREREREREKEKEREKEKEKREKEKRKEKREKEKREKEKRREKRERKRKEEKERKKKK KEK 


function: 


called by: 


calls: 


Name *name; 


int op type; 
ane x1, Vig: 


Time *tc; 


gets the storage required to store an operator or input by 


calling alloc_operator. It then fills in the operator with its na@ 


coordinates, 
load_proc() 


process operator () 
process line() 


alloc operator () 


and time constraint. 


KKK EEKEKKEKEEEEEEEKEKKKEKKKRRK RRR RRR RRR aR RR RRR 


{ 


Operator *new op; 
new op = alloc_operator(); 


new _op->name 


= name; 


NEw Op=-tame IcOnsum@ete, 


new _op->head 
new op->tail 
new_op->next 


switch (op _ type) 


NULL; 

NULL; 

NULL; 
{ 


case OPBRATOR: 


new op->optype 
new _ op-->xstart 
new _ op->ystart 
new_op->xstop 
new _op->ystop 
break; 


case EXTERNAL: 


default: 


} 


return (new_op); 


new _op->optype 
new op->xstart 
new _ op->ystart 
new_op->xstop 
new op->ystop 
break; 


break; 


li 
oo & 
=e =e =e 
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OPERATOR; 
Sel 
yi; 
az: 
y2; 


EXTERNAL; 
GO; 


ee 


Line *create_line(name,1n_ type,x1l,y1,x2,y2,dest_op) 


Name *name; 
int ln_type; 
int selec? , v2; 


Operator *dest_op; 

[ERK HK IK KK KEKE KK KKK EK KEKE KEKE KKK KEK KKK EK KEKE KEK KKK KEKEK KKK KEK KKKKEKKKKEKKEKKEKEKKKK KKK 

function: gets the storage required to store a data flow line or an 
output line by calling alloc_line. It then fills in the line struct 
with its name and coordinates. 

called by: load proc() 
process line() 

calls: alloc _line() 


external () 
Be HII HH IKK HI III IIH III IK IK II IK III IK II III KIKI III KK HII KKK KIKI KK KKK KHEKIKKKK KKK KKK / 


{ 


Line *new_ln; 


new_ln = alloc_line(); 


new_ln->name = name; 
new _ln->xstart = x1; 
new_ln->ystart = vile; 
new_ln->xstop = x2; 
new_ln->ystop = y2; 
new ln->next = NULL; 


switch(ln_ type) { 

case INPUT: 
new_ln->lntype = INPUT; 
new_ln->dest = dest op->name; 
break; 

case DATA_FLOW: 
new_ln->lntype = DATA_FLOW; 
new_ln->dest = dest_op->name; 
break; 

case OUTPUT: 
new _ln->lntype = OUTPUT; 
new _ln->dest = external () ; 
break; 

case SELF LOOP: 
new _ln->lntype = SELF_LOOP; 
new_ln->dest = dest _op->name; 
break; 

default: 
break; 

} 


return (new_ln); 
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delete op(op_1list, op) 


Operator list *op_ list; | 
Operator *op; 


[RAKRKKKRKKREKERERE RRA REAR ER KERERERREKKRKKEREKERK KK AK EDX SS eee 


fFunctewon: deletes operators from the drawing space and the internal data 


structure 


called by: process_canvas events () 


delete _input_lines() 


calls: delete input lines() 
KKK KK KKK KK KKK KKK KKK KKK KKK KKK KAKA KKK KKK KKK KK KKK KKK KKK KK KEKE KKK KKEKEKKKEKKEKSE 


{ 


Operator *dptr, 


*otemp; 
Line *1Tpter, 

*ltemp; 
Name “Ti 


/* find lines which terminate on this operator and delete them */ 
n = op-->name; 
delete input _lines(op list,n); 


otemp = op list~->head; /* put pointer at head of op list! 
if (op != otemp) { /* is the first op the one to delete? 
while (otemp->next != op) { /* if not, find the one to deletet 


otemp = otemp->next; 
} 
dptr = otemp->next; /* unlink the op to be deleted 
if (dptr->next != NULL) { 
otemp->next = dptr->next; | 
dptr->next = NULL; 
} : 
else 
otemp->next = NULL; 
} 
else { /* the first one is the one to delete 
dptr = op list=>head;, /* unlink the first op, 
op_list->head = dptr->next; | 
} 
if (dptr->head != NULL) { /* does it have any assoc lines 2 
ltemp = dptr->head; 
lptr = dptr->head; 
dptr->head = NULL; 
while (lptr->next != NULL) { 
lptr = lptr->next; 
ltemp = lptr; 
} 
lptr = NULL; 
ltemp = NULL; 
) 
dptr = NULL; | 
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delete input_lines(op_list,n) 

Operator list *op list; 

Name *n; 
[RRKREKKKKKKEKKKKEKKKKEKKKEKKEKEKEKEKKKEKEKKKEKEKEKKK KEKE KEKEEKEKKEEKKEEKEKKEKKEKKEKEKEKEK 
function: deletes lines associated with an operator when deleting operators 
called by: delete op() 
calls: delete_op() 


delete line () 
RRKEKKKKEKEKKKEKKEKRKKKEKRRKEE KER KEKEKKEK EEE KEKE KEKE KE EKKKKEEEKEKEKKEEEKEEKKKEKEKKEKEKE / 


{ 
Operator *optr; 
Line *loer, 
*ltemp; 


optr = op_list->head; 


while (optr != NULL) { /* search the entire list of operators */ 
lptr = optr->head; 
while (lptr != NULL) { /* check each line leaving each operator */ 


if (!stremp (n->string, lptr->dest->string)) { 
ltemp = lptr->next; 
/* found a line with the destination gearched for */ 
delete line(op_list,optr,lptr); /* 30 délete it */ 
/* if (optr->optype == EXTERNAL) { 
delete _op(op list,optr); 
} TA 
lptr = ltemp; 
} 
else { 
lptr = lptr->next; 


} 
optr = optr->next; 
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Operator list *op list; 
Operator *op; 
Line *ln; 
[ROR III ICICI ICICI GIGI ICICI ICICI TOK ROR IKK Iter | 


delete line (op_list, op, 1n) | 
; 


function: removes line from linked list data structure 
called by: delete_input_lines() i 
calls: none ! 


i 


BORO RRO ROR OR ORR ORO OOOO OOK ROR ROK KOK KR KR KKK KK IKK KKK KKK KK RK KR KKK KK RK aD 


{ | 
Operator *optr; 


Line Ml pt in, 
*ltemp; 
int 1n_ found = 0; 
if(op != NULL) { 
optr = op; /* start the search for the line at its source op’ 


lptr = optr->head; | 
ltemp = lptr; | 
while (lptr != inj | 
ltemp = lptr; 
lptr = lptr->next; 
: 


} 


else { /* source op is unknown - find the line 
optr = op list->head; 
while((optr != NULL) && (!ln_found)) { 


lptr = optr->head; 
ltemp = lptr; 


while((lptr != NULL) && (!ln_found)) { 
if (lptr == ln) | 
ineecound)— 1; | 
else { 


ltemp = lptr; 
lptr = lptr->next; 





| 
if (!1n_found) 
optr = optr->next; 


} 
/* unlink the line */ 
if (ltemp == lptr) { /* delete first line on list */ 
optr->head = ltemp->next; 
lptr->next = NULL; 
ltemp = NULL; 
if (optr->head == NULL) { /* first line was the only line */ 
optr->tail = NULL; 





else { 
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if(lptr == optr->tail) { /* delete last line from the list */ 


ltemp->next = NULL; 
optr->tail = ltemp; 

} 

else { 
ltemp->next = lptr->next; 
lptr->next = NULL; 

} 

optr = NULL; 
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/* delete a middle line from the list */ 


Operator *pick operator (op_list,xpick, ypick) 
Operator list *op list; 
int xpick, ypick; 
[RK IKK KH IKK KHAKI K KKK AK KKK KEKE KKK KEKE KKK KK KK KEK KAKKKKEKKKKKKKKKKEKKEKR 
function: determines if a data flow line or output line starts on an 
operator. If the search for a source operator is successful, it 
returns a pointer to that operator. 
called by: process canvas events () 
Process Operacor) 
calls: is _op_pick() 
HHH KKK KEKEKKKRKAKRKKKKKKRKKKKRKRKKKKKKKKRK KKK KKKRK KK KKK 


{ 
Operator *ptr; 


for (ptr = op_list->head; ptr != NULL; ptr = ptr->next) { 
if (ptr->optype == OPERATOR) { /* skip the null operators 
if (is_op pick(ptr->xstart, ptr->ystart, /* test for pick 


ptr->xstop, ptr->ystop, xpick, ypick)) { 
return (ptr); 


} 
return (NULL) ; 
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int is op pick (xl,y1l,x2,y2,xp, yp) 
int xl, yl, x2, y2, xp, yp; 
[REKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKAKKEKEKEKKKKKKKKEKKKAKKE 
function: determines if a pick has occurred within the bounds of an 
operator. 
called by: pick_operator() 
calls: none 


HI KI I I IK I HII KI KK IK KI IK IKK IIH I KIKI KIKI IKI IKI KK KIKI IK KKK KK KKK KKK KKK IKK KEKE / 


{ 

if (( (xp > x1) && (xp < x2) && (yp > yl) && (yp < y2) 
( (xp < xl) && (xp > x2) && (yp > yl) && (yp < y2) 
( (xp < x1) && (xp > x2) && (yp < yl) && (yp > y2) 
( (xp > x1) && (xp < x2) && (yp < yl) && (yp > y2) 
return (1); 

else 
return (0) ; 


~—" a as oo 
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Line *pick line (op list, xpick, ypick} 

[RRKKHKKEKRK KKK KEK KKK KKK KKK KKK KKK KKK AEKERKKKKKKKKEKKKKEKKKKKKKKRKKKKK KK KEE 
function: determines if a line object was picked with the mouse 

called by: peocess_ canvas events () 
calls: 1s line” prek{) ) 
HK HH HK HK KM HHH KH KKK KKK KK KKK KKK KKK KKK EKA KEKE KKK KEKKKEKEKKEKEKKKKKKKEE 





Operator list *op list; 
int xpick,. ypick; 


Operator *optr; 
Line *lptxr; 


/* search each operator’s line list */ 
for (optr = op_list->head; optr != NULL; optr = optr->next) { 
for (lptr = optr->head; lptr != NULL; lptr = lptr->next) { 
if (is_line_pick(lptr->xstart, lptr->ystart, /* test for pick ® 
lptr->xstop, lptr->ystop, xpick, ypick)) { | 
return(lptr); 


} 
return (NULL) ; 
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int is line pick(xl,yl,x2,y2,xp, yp) 
int x1, yl, x2, y2, xp, yp; 
AMARA AAA NRA AAA MAK AREMAKAKKKARRMRKK KKK KAKKKKKHRMRE KKK KKK G 
function: determines if mouse is on a line 
called by: pick line () 
calls: none 
KKK KaKKKK KH RKKKKKKKKKKKKKKKKKKKKKK KKK RK KKKEKKKKRKEMKKKKKKKKKKKKKKK KKK KKK KKK / 


{ 
if (((abs(xl-xp)+abs(yl-yp)) < PROXIMITY) || 


( (abs (x2-xp) +abs (y2-yp)) < PROXIMITY) ) 
return (1); 

else 
return (0); 
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Operator list *op list; 
Operator *op; 
[ROKR ROR RRR IOI IORI IOI IR IOI IIIA TOR IORI OI KOI TOR I ORIOTOK KITT OK RII TI KK IKK KICK KEN 
function: adds new operators to linked list of operators 
called by: load proc() 
process Operator () 
process line() 
calls: none | 
KKKKKKKKEKKKKRE KERR KKK KE RKRE KAR K ARR A % iA Ti ee ee eee 


{ 


t 
append to_op list (op_list,op) | 


if (op list->head == NULL) { 
op list->head = op; /* attach first operator to list 
op, list=7 tant =sor, 

} 

else { 
op list->tail->next = op; /* attach operator to end of lis 
op list->tail = op; 


a" — i a OO ee 
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—_——— 


append line_to_op(op,1n) 

Operator *op; 

Line *1n; 
[RRKKHKKKKKEKEKKEKKEKKEKKKKEKKKEKKEKKEKKKKKKKEKKKKEKKEEKKKKKEKKEKKKEKKEKKEKKKEEKKEKKEKKKKKEKEKKKEK 
function: attaches data flows, states, and outputs to link list of operators 
called by: load_proc() 

process line() 
calls: none 
kkkkkkkkkkkkkkkkkkkkkkkkkhkreeKKKheeKkkeaeeKkkkhhhkkkkkhkkkkkkeKKkkhkkee KK kkk hk kkk ke / 


{ 

if (op->head == NULL) { 
op->head = ln; /* attach first line to list */ 
op->tail = ln; 

} 

else { 
op->tail->next = ln; /* attach to end of line list */ 
op->tail = ln; 
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Operator *alloc_ operator () 
[RRR RK KKK RKEKKKKE KKK KKK KKK KK RRR KEK KKK KK KK KKK KKK KKKKK KKK KEKKKK KKK KK KKK KKKKKEK 
function: allocates dynamic storage for operators their inputs 
called by: create op) 

calls: none 
KRHEEKKKKKEKEKEKKEKKKKKKEKKKKKKEKKKKKKKE KKK KKK KKK KKK KKK KK KK KKK KKK KKK KKKKKKKKKKKEKKKKEE 


{ 


Operator *op; 


op = (Operator *)malloc (sizeof (Operator) ); 
return (op) ; 
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Line *alloc line () 
ee A KARRAKEARKKKAKAKKKEKK KK KK KKKKKKKKKKKKKKKKKKKKKEKKKKKKEKKEREKEKERERERKKKKKKKK 


function: allocates dynamic storage for data flows and outputs of an operator 
called by: create _line() 


calls: none 
Fe He AK TOK III III IOI KI KK III KK II KI IK KK II KK IKK II KKK IKK KKK KKK KKK KKK KKKEKKKK KKK KK KKK KK / 


{ 


Line *ln; 


ln = (Line *)malloc (sizeof (Line) ) ; 
return (ln) ; 
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input _ text (item, value, event) 


Panel item item; 
prt value; 
Event *event; 


[RHR KKKKKKKKKKK KK KK KKK KK KK KKK KKKKK KK KKK KK KKKEKKKKKKKKKKKEKKKKKKKKKKKKKKK KK KER 


function: reads the names from the name panel 
called by: notifier when entering an object identifier name 
calls: is valid ada id() 
display error msg() 
KKK KKK KKK KKK KKK KKK KKK KKK KK KKK KKK KK KKK KKK KKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKE 


{ 
tmp buf = malloc(80); | 
/* initialize the storage 
tmp but 0) sae 7 
strepy(tmp_buf, (char *)panel_ get value (object name) ); 
/* check to see if the name is an ada identifier */ 
if (is_valid_ada_id(tmp_buf)) { 
display error _msg(1l); 
name _ checked = 1; 
} 
else 
display error msg(2); 
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display error _msg(msg id) 


int msg_ id; 


[RAKHI HEE RE KEKR EKER EKER EKER ERR KEKE KR KERIKERI KKK EKER EKKEKKKKKKK 


function: displays warnings and error messages in the message panel 
called by: process object () 


input text () 
input_time () 
quit _proc() 


calls: none 
RAKHI HHI KI KKK IKKE KR IE KKK KKK KIKI KEKE KKKEKKEKKEKEKKKEKKKAKKKKKKKKKKKKKKK / 


{ 


char *msg; 


msg = malloc(61); 
switch(msg_ id) { 
case 1: 
msg = " MESSAGE PANEL: 
break; 
case 2: 
msg = " MESSAGE PANEL: SYNTAX ERROR in ADA identifier 
break; 
case 3: 
msg = " MESSAGE PANEL: SYNTAX ERROR in Maximum Execution Time 
break; 
case 4; 
msg = " MESSAGE PANEL: ERROR - Either NAME or TIME not read 
break; 
case 5: 
msg = " MESSAGE PANEL: ERROR - NAME not read 
break; 
case 6: 
msg = " MESSAGE PANEL: WARNING - The graph has not been stored! 
break; 
default: 
break; 
} 
window set (message_panel,0); 
panel set (message, PANEL_LABEL STRING, msg, 0); 
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Name *get name () 
[BR II IORI RIOR ROTOR RIOR RIOR ORI OIOIOIORROIOK RIOR IORI KOTOR IOI IOI IK KOTOR IOI OK IOI IIA KIS IK 
function: creates a dynamic name structure 
called by: process operator () 
process line() 


calls: none 
KAKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKEKKKK KK KKK IKKKIEKKKKKIIKKKIKKKHKAKKKAKAAKKKK 


Name *n; 
n = (Name *)malloc (sizeof (Name) ) ; 
strcopy (n->string, tmp buf); 


n->length = strlen(n->string) ; 
return (n); 
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display name(n, otype,x1l,yl,x2,y2) 


Name *n 
int ot 


e 
tA 


ype,xl,yl, X2,Y2; 


[RRR HKKKKKKEKEKKIKKKE KKK KKK KKK EKA KICK KEK KK KEK KEK KK KKK KE KK KEKKKKEK KKK KEKKEKKKKEKKKEE 


function: d 


O 
n 
5 
° 


called by: p 


Pp 
xr 


calls: n 
KIA KKK AKA K KKK IKK KK KKK KK KIK KKK KKK KKK KAKA KKK EKA KKK KKK KKK KKK KKK KAKA KEKE KKKKKKEKE / 


{ 


isplays the name of the object which the user has drawn. 

perator names are centered within the operator, data flow line 
ames start above the center of the line, input names start above 
he initial point of the line, and output names start at the end 
£ the output line. 

rocess operator () 


rocess_ line () 
edraw_ diagram () 
one 


float xcent,ycent; 
xcent = xl + ((x2 - x1) / 2.0); 
Meent = yl + ({y2 - yl) / 2.90); 
switch(otype) { 
case OPERATOR: 
xcent = xl + ((x2 - x1) / 2.0); 
ycent = yl + ((y2 - yl) / 2.0); 
pw_text (canvas _pixwin(drawing canvas), 
(int) xcent- ((n->length) /2) *8, 
(int) ycent+5, PIX SRC, NULL, n->string) ; 
break; 
case INPUT: 
pw_text (canvas_pixwin (drawing canvas) ,x1,y1l,PIX_SRC, 
NULL, n->string) ; 
break; 
case OUTPUT: 
pw_text (canvas_pixwin (drawing canvas) ,x2,y2,PIX_SRC, 
NULL, n->st ring) ; 
break; 
case DATA FLOW: 
xcent = (x2 - x1) / 2.0; 
ycent = (y2 - yl) / 2.0; 
pw_text (canvas_pixwin (drawing canvas) ,x1+ (int) xcent, 
yl1+ (int) ycent, PIX_SRC, NULL, n->string) ; 
break; 
case SELF LOOP: 
xcent = xl + ((x2 - x1) / 2.0); 
pw_ text (canvas_pixwin(drawing canvas), 
(int) xcent- ((n->length) /2) *8, 
(int) y2-7,PIX_SRC, NULL, n->string) ; 
break; 
default: 
break; 
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int is valid _ada_id(tmp_buf) 
char tmp buf[80]; 


[KIRK RR RR RR RA RI RRR OK IKK ROK OK KKK KOK TOTO TOR TOT TT TK IK 


function: checks to see if a name is a legal ada identifier 

called by: input text () 

calls: none 

KAKA KKK KKK KK KEK KKK KEK KKK KK KKK KKK KKK KKK KKK KKK KK KK KK KKEKKKKKKKKKKKKKKKKKKKKS 


{ 





Lne space found = 0; 
rae i= 1; 


if (isalpha(tmp buf[0])) { 
while (2 <= strlen((char *)tmp buf) “= 33)ay 
if(!isgraph(tmp buf[i])) { 
Space, teunds— 2, 
i =i1+ 1; 
} 
else { 
if (((isalnum(tmp_buf[iJ)) {| (tmp_buf[i]==" ')) && ! (space_ found 
1=i+t1; 
else 
return (Q); 


} 


return (1); 


} 
else 
return (0); 
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Zoom time(item, value, event) 


Panel item item; 
int value; 
Event *event; 
[RARE KKKEKKKKKEKKKKKKKKKEKKKKKKKEKKEKKKKKEEKKKK KKK KKK KKKEKKKKKKEKAKKKKKKEKEKKKKEKKEKEKKER 
function: gets and checks time constraints 
called by: notifier 
calls: display error msg() 


is valid time const () 
RIKKI KKK KKK KKK KEKE KK KKK KKK IKK KK KEK KKK KK ERK KKK KKK KKK KK KEKE KEK EKEKK KEKE KKK / 


{ 
tmp bufl = malloc(12); 


Empebutt(O) =’ '; 
strcepy(tmp_bufl, (char *)panel_get_value(time_constraint) ); 
if (is_valid_time_const(tmp_bufl)) { 
display error _msg(l); 
time checked = 1; 
} 
else 
display error msg(3); 
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int is valid time_const (tmp_buf1) 
char tmp_bufl1[{12]; 


[RR RRR RK KKK KKK KERR KK KKK KK KKK KKK KKK KKK KKK KEK KKK KKK KEK KKK KKK KK KKK KKK KKK KK KKKEKE 


function: checks syntax for time constraint 
called by: input_time() 
calls: none 


KR KKK KKK KKK KKK KKK KEKE KKK KKK KKK KKK KEK KKK KKK KEK KKK KKK KKK KKK KK KKK KKEKKEKKKKEKKKKKKEKE 


{ 
int nondigit found = 0; 
int letter prev_found = 0; 
int mfound = 0; 


int ufound = 0; 
int done = 0; 
int i= 1; 


if (isdigit (tmp buf1[(0])) { 
while (i <= strlen((char *)tmp_bufl) - 1) { 
1f (!isalnum(tmp_ bufl{i]J)) 
return (0); 
else { 
if (isdigit (tmp_bufl[i]}) &&!nondigit found) 
i =i +1; 
else { 
1f (isdigit (tmp_bufl[i])) 
return (0); 
else { 
nondigit found = 1; 
switch(tmp_bufl[i]) { 
ease uu = if ('letter prey founda 
ufound = 1; 
letter prey tound.=. 1, 


i =i + 1; 
) 
else 
return (Q); 
break; 


case ‘’s’: if (!letter prev found) { 
fetter prev found = 1; 
1 =i +1; 
} 
else { 
if ((ufound||mfound) &&!done) { 
done = 1; 
i =i + 1; 
} 
else 
return (0); 
} 
break; 
case ‘m’: if (!letter prev found) { 
mfound = 1; 
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! etter prev found'= 1; 
1= i+ 1; 
} 
else 
return (0) ; 
break; 
default : return(0); 
break; 


) 
} 
if ((ufound&&!done) || (!nondigit found) ) 
return (0) ; 
} 
else 
return(Q); 
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Time *get time const () | 
[3 ICICI ICI TOI ICICI I TICE STIR SN ITO AJIT IO SE SIC 


function: creates initial time structure for objects 
called by: process (operator) 
Proceso uli ne () 
calls: none 
KAAKKKKKKAKKKKKAKKKKKAKKKKKAKKKAKKKKKAKKAKKKKAKKKKEKKKKKKKKKEKKKKKKAKKKKAKAKKAKKAKKKE) 


{ 


Time *tc; 


/* get storage for the time constraint */ 
te = (Time *)malloc(sizeof (Time) ); 
switch(edit mode) { 
case OPERATOR: 
strepy (tc->string,tmp bufl); /* assign input string */ 
tce->length = strlen(tc->string); /* find length of the string */ 
break; 
case INPUT: 
St repyite-—-- string, 0s"); 
tce->length = 2; 
break; 
default: 
break; 
} 


return (tc) ; 
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Saisplayste(tc, x1, ylyx2,y2) 

Time *tc; 

mnie xl yl, x2, y2; 
[RRKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKAKKKKKKKKKKKKKKK KKK KKK KKKKKKKKKKK KKK KKK KKK 
function: displays time constraint in the drawing space 
called by: process operator () 

redraw diagram() 

calls: none 
kkkkkk kkk kkkkkkkkkhk keke KKK KKK hh kK KKK KKKKKKKK Kh hhh kkk kK KKK KK KKK KKK KKK KKK / 


{ 


float xcent; 
xcent = xl + ((x2 - x1) / 2.0); 


pw_text (canvas pixwin(drawing_canvas), (int) xcent- ((tc->length) /2) *8, 
(int) yl1-5, PIX_SRC,NULL, tc->string) ; 
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Name *external () 
[RRA IKI HKIK IK RAK KICK KHAKI EKER KKK AKER EKER EK EKEKEKEKKKKEKKAKEREREKKKKKEE KK ee ] 


function: returns the name "EXTERNAL" whenever it is called. It is 
used to provide the names for the source of input lines and 
destination of output lines. 
called by: create line () 
process line () . 
calls: none 


KKK KKK KKK KKK KKK KKK KKK KK KKK KKK KKK KKK KKK KKK KKK KKK KKKKKEKREKKKKKKKKKKKEKE: 


{ 


Name *n; 





n = (Name *)malloc(sizeof (Name) ); /* alloc storag 
strcpy (n->string, "EXTERNAL") ; /* assign nam 
n->length = 8; /* assign name: 


return (n) ; 
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create PSDL() 
[RRR KKK KK KKK KKK KKK HK KK IKK KK KKK KK IK KIKI KK IKK KI KK ERI KKK KKK KKK KKK KI KKEKKKKKK KK EEK 


function: creates the PSDL statements represented by the user’s data 


flow diagram. A PSDL statement of the form 

output_line name.source_name[:time_constraint]->destination_name 
will be constructed from the information contained in the operator 
list. 


called by: store_proc() 


calls: none 
KHKHKHKKHKKKKK KKK KK EKER KKK KKK KKK KKK KEKE KEKE KK KEK K EEK KEE KKK KKKKKKKKEKKKKKKEKKKKAKKAKKK / 


{ 


Operator *op ptr; 


Line *output_ ptr; 
char *psdl; 

char *period = "."; 
char “Colon = ets 
char *arrow = "=>"> 


f = fopen("/n/suns2/work/caps/prototypes/graph. links", "w") ; 
psdl = malloc(270); 
psdl[O] =’ '%; 


op ptr = op_list->head; /* point at head of the operator list */ 
while (op ptr != NULL) { 
output ptr = op ptr->head; /* point line ptr at head of line list*/ 


while (output ptr != NULL) { 
/* assemble the psdl statement by concatenating the parts of the 
PSDL statements together */ 
psdl = strcat (psdl1, output_ptr->name->string) ; 
psdl strcat (psdl, period) ; 
psdl strcat (psdl,op_ptr->name->string) ; 
psdl = strcat (psdl, colon) ; 
if ((op_ptr->optype == OPERATOR) && 
(op_ptr->time_const->string != "0s")) 
psdl = strcat (psdl,op_ptr->time_const->string) ; 
psdl = strcat (psdl, arrow) ; 
psdl = strcat (psdl, output_ptr->dest->string) ; 
fprintf (f,™%s\n",psdl); /* store link stmt in file */ 
psd1l[0}] =’ '; /* reinitialize */ 
output ptr = output _ptr->next; 


} 

op ptr = op ptr->next; 
} 
fclose (f); 
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store diagram() i 
[ KRKKKIKAKKKKIAKEKKKKKKKAEKKKKEKKKKKKKAKKKAKAKKKAKKKKKKKEKKKEKKKKAKK KKKKK KE Xe 
function: writes the current prototype design to a file 

called by: store _proc() 

calls: none . 
KKK KKK KKK KKK KK KKK KKK KKK KKK IKK KEI K KKK KKK KEKE KKK KKK KK KKKEKEKKKKKKKEKKKKEKKKKKEKKEEK 


{ 
Operator *op ptr; 
Line TENS pty 


g = fopen("/n/suns2/work/caps/prototypes/graph.pic", "w") ; 
op ptr = op _list->head; 
while(op ptr f= NULL) { 
fprintf (g,"%d\n",op_ ptr->optype) ; 
fprintf(g, "td\n",op ptr->xstart) ; 
fprintf (g, "td\n",op_ptr->ystart) ; 
fprintf(g,"%sd\n",op_ ptr->xstop) ; 
fprint£ (g, "td\n", Op (ptr --ystop) - 
fprintti(g, "%s\n", op pte —>name=> string): 
fprintf(g, "%s\n",op_ptr->time_const->string) ; 
If ptr = Cpeptr = mead, 
while(ln ptr != NULL) { 
fprintt (g, “Sd\ne, in ptxr=>intype). 
fprintf (g, "td\n",1ln_ ptr->xstart) ; 
fprintf(g,"%d\n",ln ptr->ystart) ; 
fprintf(g,"td\n",ln ptr->xstop) ; 
fprint£ (g, "td\n", In ptr -=systop), 
fprint£ (g, “%s\n", in per name >sering, 
fprintf(g,"%s\n",ln ptxr->dest-—>string) ; 
in ptr i apece-nexe, 
} 
op_ptr = op_ptr->next; 
} 
fclose(ae: 
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redraw diagram () 
[ARI IOI ITO IO IO IOI IO OOO IO IO IO IO ITOK TOK I tk 


function: redraws the diagram in the drawing space 
called by: load _proc() 


process canvas events () 


calls: draw_object () 


display name () 
display tc() 
draw_arrowhead () 


HA KKK KEKE KE KKK KK EK K EKER KKK KKK EKEKEEKKKKKKKKKKKKKKKKKKKK KKK KKK KKK KKK KKK KK RR KK RK / 


{ 


Operator *op ptr; 
Line *ln ptr; 


pw_writebackground (drawing pw,0,0, 
window get (drawing canvas,CANVAS WIDTH), 
window _get (drawing _canvas,CANVAS_HEIGHT), 


PIX SRC); 
op_ptr = op_list->head; 
while (op ptr != NULL) { 


if(op_ptr->optype == OPERATOR) { 
draw object (op ptr->optype,op ptr->xstart,op ptr->ystart, 
Op_ptr->xstop,op_ptr->ystop) ; 
display name(op ptr->name, OPERATOR, op ptr->xstart, 
op ptr->ystart,op_ ptr->xstop,op ptr->ystop); 
display tc(op_ptr->time_const,op_ptr->xstart,op_ptr->ystart, 
op ptr->xstop,op_ptr->ystop) ; 
} 
In_ ptr = op_ptr->head; 
while(ln ptr != NULL) { 
draw object (1ln_ptr->lntype,1n_ptr->xstart,1ln_ ptr->ystart, 
ln_ptr->xstop, 1ln_ptr->ystop); 
if (ln_ptr->lntype == SELF_LOOP) 
draw arrowhead (ln _ptr->xstop,1n_ptr->ystop, 
ln_ptr->xstop,ln_ptr->ystart); 
else 
draw arrowhead (ln ptr->xstart,1ln_ptr->ystart, 
ln_ptr->xstop,1ln_ptr->ystop); 
display _name(ln_ptr->name,1n_ptr->lntype,1n_ptr->xstart, 
1n_ptr->ystart,1ln_ptr->xstop,1n_ptr->ystop) ; 
ln_ptr = ln_ptr->next; 
} 
op ptr = op_ptr->next; 
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draw _arrowhead(xl, yl, xp 


[LRKRKKKEKKKKEKKKEKKKKEKEKEKRERKKEKKKKKKKKERAKKKKRAKKKKKRKKKKKKKKKARKAK KK KK Ke re 


function: draws an arrow head at the end of a line at the appropriate angle 
called by: process_line() 


calls: none 
KEKE KKKKKKKKKKKEKKKEKKEKEKRKKEK KKK KKK KKK KK KKKKK KEKE KKK KEK KKKKKKKKKKKKKKEKKKKKKKKEKE 


{ 


int cele yes ey 





redraw arrowhead () 


int xl trans, yl_trans, x2_trans, y2 trans; 
int xptl, yptl,) xpeZ; vere, 

xptl_trans, yptl_trans, xpt2_trans, ypt2_ trans; 
double length, theta; 


/* translate the line to the origin */ 

xl trans = oct. x2: 

yl_ trans = yl - y2; 

/* find the length of the line */ 

length = sqrt (pow ((double)xl_trans,2.0) + pow( (double) yl _trans,2.0)); 
/* find the angle between the line and the x axis */ 

theta = acos ((double)x1_trans/length) ; 

/* calculate the coords of the points of the arrowhead */ 


xptl = ARROW_LENGTH * cos(theta + PI / 6.0); 
yptl = ARROW LENGTH * sin(theta + PI / 6.0); 
xpt2 = ARROW_LENGTH * cos(theta - PI / 6.0); 


ypt2 = ARROW_LENGTH * sin(theta - PI / 6.0); 
/* reflect y coords across x axis if yl_trans is negative */ 
if (yl trans <0)a 
yptl = -yptl; 
ypt2 = -ypt2; 
} 
/* translate the coords of the arrowhead out to the posit of the line */ 
xptl trans = xptl + x2; 
yptl_ trans = yptl + y2; 
xpt2 trans = xpt2 + x2; 
ypt2 trans ypt2 + y2; 
/* draw the point of the arrow */ 
pw_vector (drawing pw, xptl_trans, yptl_trans, x2, y2, PIX_SRC, 1); 
pw_vector (drawing pw, xptZ trans, ypt2_ trans, x2, y2, PIX_SRC, 1); 
pw_vector(drawing pw, xptl_trans, yptl_ trans, xpt2_trans, ypt2_ trans, 
PIX SRC, 1); 


ll 
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APPENDIX E LINK STATEMENT ANALYZER 


Program: nodes.p 
Author: Hank Raum 
Last Modified: 9 December 89 by Laura J. White 


program CreateNodes (input, output) ; 


const (* Global Constants *) 
period = ’.’; 
colon = ’:;3° 
arrow = /-’ 
blank = ’ : 
EXTERNAL = ’ EXTERNAL 


= Ye oe 


type 

string80 = packed array [0..79] of char; 

DataPtr = “DataType; 

DataType = record (* Node for Linked List *) 
Name: string80; (* of Nodes *) 
Link: DataPtr; 
end; (* DataType *) 

OperPtr = “Operator; 


Operator = record (* Node of Linked List of Operators *) 
OpName: string80; (* Operator Name *) 
InputList: DataPtr; (* Head Pointer to Input List *) 
InListTail: DataPtr; (* Tail Pointer to Input List *) 
OutputList: DataPtr; (* Head Pointer to Output List *) 
OutListTail: DataPtr; (* Tail Pointer to Output List *) 
StateList: DataPtr; (* Head Pointer to State List *) 
StateListTail: DataPtr; (* Tail Pointer to State List *) 
MET: string80; (* Maximum Execution Time *) 


Link: OperPtr; 
end; (* Operator *) 


var 
OpHead: OperPtr; (* Head of Operator List *) 
OpTail: OperPtr; (* Tail of Operator List *) 
DataHead: DataPtr; (* Head of Data List *) 
DataTail: DataPtr; (* Tail of Data List *) 

(* a“ ee ee eee eee eee ee ee@er ewe em OO ee ee @ eee ww ew we ew ew ew ew ew ew ee ew ew ew oe *) 
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procedure ReadToken (delimeter:char; 
var token:string80); 


(* Reads PSDL Link statements from standard input, one token at *) 
(* a time. Delimeters are: period, colon, arrow and End of Line *) 


var 
ndx: integer; 
ch: char; 


begin 
ndx := Q; (* initialize *) 
read (ch); 
while (ch <> delimeter) and (not eoln) do 
begin 
token[ndx] := ch; (* Gets token character by character *) 
read (ch) ; (* until delimeter or eoln *) 
ndx := ndx + 1; 
end; (* while*) 
if eoln then token[ndx}) := ch; (* Gets last character before *) 
if delimeter = arrow then (* end of line *) 
begin 
read(ch); read(ch); (* remove rest of arrow *) 
end; (22%) 
if eoln then readin; (* resets line *) 
end; (* ReadToken *) 
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procedure ReadOperMet (var Operl, Met: string80) ; 


(* Reads PSDL Link statements from standard input, one token at *) 
(* a time. Determines Operatorl and Maximum Execution Time *) 


var 
ndx:integer; 
ch: char; 


begin 
ndx := 0; (* anitialize *) 
read (ch); 
while (ch <> colon) and (ch <> arrow) do 
begin 
Operl[(ndx] := ch; (* Gets token character by character *) 
read (ch) ; (* until delimeter or eoln *) 
ndx := ndx + 1; 
end; (* while*) 
if ch = colon then (* end of line *) 
begin 
ndx := 0; 
read (ch); 
while ch <> arrow do 
begin 
Met [ndx] := ch; (* Gets token by character *) 
read(ch) ; (* until delimeter or eoln *) 
ndx := ndx + 1; 
end; (* while*) 
end; (* af *) 
read(ch); read(ch); (* remove rest of arrow *) 
end; (* ReadToken *) 
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function OpSearch (Head: OperPtr; 
Target: string80): OperPtr; 


(* Searches Operator List for Target string, returns pointer *) 
(* to target if found, otherwise NIL *) 


begin 
if Head = nil then 
OpSearch := nil (* empty list *) 
else if Head” .OpName = Target then 
OpSearch := Head (* target found *) 
else 
OpSearch := OpSearch(Head”.Link, Target); 
end; 
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procedure OpAdd (var Head: OperPtr; 
var Tail: OperPtr; 
Target: string80); 


(* Adds new Operator to end of linked list *) 


var 
p: OperPtr; (* temp pointer *) 


begin 
if Head = nil then (* List is empty *) 
begin 
new (p) ; (* Create new head node *) 
Head := p; 
Tail := p; 
p” .OpName := Target; (* Initialize new list *) 
p°.InputList := nil; 
p*~.InListTail := nil; 
p~ .OutputList := nil; 
p~ .OutListTail := nil; 
p”.Link := nil; 
end (* if *) 
else (* List not empty *) 

begin 
new (p) ; (* Add new node after tail *) 
Tail*~.Link := p; 
Tail := Tail”~.Link; 
p”~ .OpName := Target; (* Initialize new lists *) 
p* .InputList := nil; 
p*~.InListTail := nil; 
p*~.OutputList := nil; 
p”.OutListTail := nil; 
p” .StateList := nil; 
p*~.StateListTail := nil; 
p~.Link := nil; 
end (* else *) 

end; (* OpAdd *) 


(* KK ee EE EEO eee ee Ree Oe ee we ee ew ew ew ew ew ee ee ee ee ee ee — —*) 
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function Search (Head: DataPtr; 
Target: string80): DataPtr; 


(* Searches Data Listfor Target string, returns pointer *) 
(* to target if found, otherwise NIL *) 


begin 
if Head = nil then 
Search := nil (* empty list *) 
else if Head” .Name = Target then 
Search := Head (* target found *) 
else 
Search := Search(Head”.Link, Target); 
end; (* Search *) 
(k----------------- -- -- -- - - - - - - - - - - - - - - - - - -- -- - -- === *) 
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:’ 


procedure Add (var Head: DataPtr; 


var Tail: DataPtr; 
string80) ; 


Target: 


(* Adds new Data to end of linked lists *) 


var 
p: DataPtr; 


begin 

if Head = nil then 
begin 
new (p); 
Head := p 
Tail := p; 
p° .Name := Target; 
p”.Link := nil; 

end (Sat) 

else 
begin 
new (p); 
Tail” .Link := p; 


Tail := Tail”.Link; 


p” .Name := Target; 

p”’.Link := nil; 

end (* else *) 
end; (* OpAdd *) 


(* 


(* 


(* 


(* 


(* 


(* 


(* 
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Temp pointer *) 


List is empty *) 


Create new node *) 


Initialize new lists *) 


List not empty *) 


Add new node after tail *) 


Initialize new lists *) 


procedure LoadDataStructure (var OpHead, OpTail: OperPtr; 
var DataHead, DataTail: DataPtr); 


(* Loads tokens into Data Structures *) 


var 
Current: OperPtr; (* Temp pointer *) 
Data, Met: string80; (* PSDL Tokens *) 
Operl, Oper2: string80; 


begin 
Data := blank; (* Initialize Strings *) 
Operl := blank; 
Met := blank; 
Oper2 := blank; 


while not eof do 
begin (* Get tokens *) 
ReadToken (period, Data) ; 
ReadOperMet (Operl, Met); 
ReadToken(!’ ',Oper2); 
if Operl <> EXTERNAL then (* Keyword EXTERNAL is not *) 
begin (* an Operator *) 
(KRKKKKKKKKKE segv on next statement KHKKKKKKKKEE | 
Current := OpSearch (OpHead, Operl) ; 
if Current = nil then 
begin (* Add Operator 1 *) 
OpAdd (OpHead, OpTail, Operl1) ; 
Current := OpSearch (OpHead, Operl) ; 
end; (* if *) 
Current” .MET := Met; (* Enter Maximun Execution Time *) 
(* Add Data to Operators Output List *) 
if Operl = Oper2 then 


begin 
if Search(Current”.StateList,Data) = nil then 
Add (Current~ .StateList, Current” .StateListTail, 
Data); 
end 4 
else 


if Search(Current” .OutputList,Data) = nil then 
Add (Current .OutputList, Current” .OutListTail, 


Data); 
end; (* if *) 
if Oper2 <> EXTERNAL then (* Keyword EXTERNAL is not *) 
begin (* an Operator *) 
Current := OpSearch (OpHead, Oper2) ; 
if Current = nil then 
begin (* Add Operator 2 *) 


OpAdd (OpHead, OpTail, Oper2) ; 
Current := OpSearch (OpHead, Oper2) ; 
end; (\a4t *) 
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(* Add Data to Operators Input List *) 
if Operl = Oper2 then 
begin 
if Search (Current”™.StateList,Data) = nil then 
Add (Current” .StateList, Current” .StateListTail, 
Data) ; 
end 
else 
if Search(Current” .InputList,Data) = nil then 
Add (Current”~ .InputList, Current” .InListTail, 
Data); 
end; (* if *) 
(* Enter new internal Data Streams in Data List *) 
if ((Operl <> EXTERNAL) and (Oper2 <> EXTERNAL)) and 
(Operl <> Oper2) then 
if Search (DataHead,Data) = nil then 
Add (Dat aHead, DataTail, Data); 


Data := blank; (* Reset Strings *) 
Operl := blank; 
Met := blank; 
Oper2 := blank; 
end; (* while *) 
(* LoadDataStructure *) 
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procedure WriteString(var File:text; Str: string80); 


var 
ndx: integer; 


begin 

ndx := 0; 

while Str{ndx] <> ’ ’ do 
begin 
write (File, Str[ndx]); 
ndx := ndx + 1; 
end; (* while *) 

end; (* WriteString *) 
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procedure MakePSDL(Head: OperPtr) ; 


(* Generates partial PSDL Specification for each new Operator *) 
(* in the Graphical decomposition *) 


type 
Sstring42 = packed array [0..41]} of char; 


var 
Current: OperPtr; (* Temp pointers *) 
InTemp: DataPtr; 
OutTemp: DataPtr; 
StateTemp: DataPtr; 
OutFile: text; 


NodeName: string42; (* Unix file name *) 
begin 

Current := Head; 

NodeName := ’/n/suns2/work/caps/prototypes/NewNode.01’ ; 


while Current<> nil do 
begin 
rewrite (OutFile, NodeName) ; (* Create new file *) 
(* output PSDL *) 
write (OutFile,’OPERATOR ’); 
WriteString (OutFile, Current” .OpName) ; 
writeln (OutFile) ; 
writeln (OutFile) ; 
writeln (OutFile,’ SPECIFICATION’ ); 
writeln (OutFile) ; 
InTemp := Current” .InputList; 
if InTemp <> nil then (* Generate Input list *) 
begin 
write (OutFile,’INPUT ’); 
WriteString (OutFile, InTemp’ .Name) ; 
writeln (OutFile) ; 
InTemp := InTemp”~.Link; 
while InTemp <> nil do 
begin 
write (OutFile, ’ Gn Ne 
WriteString (OutFile, InTemp”~ .Name) ; 
writeln (OutFile) ; 
InTemp := InTemp*.Link; 
end; (* while *) 
writeln (OutFile) ; 
end; (* if *) 
OutTemp := Current”.OutputList; 
if OutTemp <> nil then 
begin (* Generate Output list *) 
write (OutFile,’OUTPUT ’); 
WriteString (OutFile, OutTemp” .Name) ; 
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writeln (OutFile); 


OutTemp := OutTemp’ .Link; 
while OutTemp <> nil do 
begin 
write (OutFile, ’ a a 


WriteString (OutFile, OutTemp” .Name) ; 
writeln(OutFile) ; 
OutTemp := OutTemp” .Link; 
end; (* while *) 
writeln (OutFile) ; 
end; (* af *) 
StateTemp := Current” .StateList; 
if StateTemp <> nil then 
begin (* Generate State list *) 
write (OutFile,’STATE ’); 
WriteString (OutFile, StateTemp~ .Name) ; 
writeln(OutFile); 
StateTemp := StateTemp”.Link; 
while StateTemp <> nil do 
begin 
write (OutFile, ’ oe 
WriteString (OutFile,StateTemp” .Name) ; 
writeln(OutFile); 
StateTemp := StateTemp~.Link; 
end; (* while *) 
writeln(OutFile) ; 
end; (* if *) 
write (OutFile, ’MAXIMUM EXECUTION TIME ’); 
WriteString (OutFile, Current” .MET) ; 
writeln (OutFile) ; 
writeln (OutFile); 
writeln(OutFile,’END’); 
Current := Current” .Link; 


(* Dynamically create new file name *) 
if NodeName[41] = '9’ then 
begin 
NodeName [41] := '0°; 
NodeName [40] := succ (NodeName [40]) ; 
end (* if *) 
else 
NodeName[41] := succ(NodeName [41]); 
end; (* while *) 
(* MakePSDL *) 
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procedure MakeDataStream (Head: DataPtr); 


(* Generate PSDL Data Stream *) 
var 

Temp: DataPtr; 

Out file: text; 


begin 
rewrite (Out file, ’/n/suns2/work/caps/prototypes/psdl.ds’); 
writeln (Outfile) ; 
if Head <> nil then 
begin 
Temp := Head; 
write (Outfile,’DATA STREAM ’); 
WriteString (Out file, Temp” .Name) ; 
writeln (Out file) ; 
Temp := Temp” .Link; 
while Temp <> nil do 
begin 
write (Outfile, ’ ae 
WriteString (Out file, Temp” .Name) ; 
writeln (Outfile) ; 
Temp := Temp” .bLink; 
end; (a while *) 
writeln (Outfile) ; 
end; (i cls a) 
end; (* MakeDataStream *) 
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begin (* main *) 
LoadDataStructure (OpHead, OpTail, DataHead, DataTail); 
MakePSDL (OpHead) ; 
MakeDataStream (DataHead) ; 

end. 
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APPENDIX F ICON FOR GRAPHIC EDITOR 


ee ee ee 
ye file: editor.icon 

/* purpose: icon for graphic editor 

/* author: roger thorstenson 

/* date: dec 1989 
J®——------------_-__-_-_-- ~~ --------- ~~ -- +--+ + + + ee 


/* Format _version=1, Width=64, Height=64, Depth=1, Valid bits per item=16 
if 
OxFFFF, OxF FFF, OxFFFF, OxFFFF, 0x8000, 0x0000, 0x0000,0x0001, 
0x8000, 0x0000, 0x0000, 0x0001, 0x8000, 0x0000, 0x0300, 0x0001, 
0x8000, 0x0000, 0x0F00, 0x0001, 0x8000, 0x0000, 0x1B00, 0x0001, 
0x8000, 0x0000, 0x3300, 0x0001, 0x8000, 0x0000, 0x6500, 0x0001, 
0x8000, 0x0000, 0x8600, 0x0001, 0x8000, 0x0000, 0x8A00, 0x0001, 
0x8000, 0x0001, 0x1200, 0x0001, 0x8000, 0x0003, 0x1600, 0x0001, 
0x8000, 0x0002, 0x2400, 0x0001, 0x8000, 0x0006, 0x2400, 0x0001, 
0x8000, 0x000A, 0x4800, 0x0001, 0x8000, 0x0012, 0x9800, 0x0001, 
0x8000, 0x0014, OxF000, 0x0001, 0x8000, 0x0025, 0xA000, 0x0001, 
0x8000, 0x0045, 0x2000, 0x0001, 0x8000, 0x0086, 0x2000,0x0001, 
0x8000, 0x008C, 0x4000, 0x0001, 0x8000, 0x008C, 0x8000, 0x0001, 
0x8000, 0x0388, 0x8000, 0x0001, 0x8000, 0x028B, 0x0000, 0x0001, 
0x8000, 0x0297, 0x0000, 0x0001, 0x8000, 0x04BA, 0x0000, 0x0001, 
0x8000, 0x04A2, 0x0000, 0x0001, 0x8000, 0x08C4, 0x0000, 0x0001, 
0x8000, 0x08C8, 0x0000, 0x0001, 0x8000, 0x1888, 0x0000, 0x0001, 
0x8000, 0x1990, 0x0000, 0x0001, 0x8000, 0x3930, 0x0000, 0x0001, 
0x8000, 0x2A60, 0x0000, 0x0001, 0x8000, 0x2BE0, 0x0000, 0x0001, 
0x8000, 0x2E80, 0x0000, 0x0001, 0x8000, 0x4880, 0x0000, 0x0001, 
0x8000, 0x4900, 0x0000, 0x0001, 0x8000, 0xD200, 0x0000, 0x0001, 
0x8000, 0x9600, 0x0000, 0x0001, 0x8000, 0xAC00, 0x003F,0xE001, 
0x8000, 0xC800, 0x0020, 0x2001, 0x8001, 0x7000, 0x0020, 0x2001, 
0x8001, 0xc000, 0x03FF, 0OxFE01, 0x8003, 0xC000, 0x0200, 0x0201, 
0x8003, 0x0000, 0x02E5, 0x2A01, 0x8002, 0x0000, 0x0247, 0x3201, 
0x8006, 0x0000, 0x02E5, 0x2A01, 0x800C, 0x0000, 0x0200, 0x0201, 
0x8008, 0x0000, 0x03FF, OxFE01, 0x8000, 0x0000, 0x0000, 0x0001, 
OxFFFF, OxFFFF, OxFFFF, OxFFFF, 0x8000, 0x0000, 0x0000, 0x0001, 
0x8000, 0x0410, 0x2000, 0x0001, 0x8000, 0x0410, 0x2000, 0x0001, 
0x8000, 0x0400, 0x2000, 0x0001, 0x8078, 0x7470, OxF878,0xB801, 
0x8084, 0x8C10, 0x2084, 0xC401, 0x8084, 0x8410, 0x2084,0x8001, 
Ox80FC, 0x8410, 0x2084, 0x8001, 0x8080, 0x8410, 0x2084,0x8001, 
0x8084, 0x8C10, 0x2484, 0x8001, 0x8078, 0x7410, 0x1878, 0x8001, 
0x8000, 0x0000, 0x0000, 0x0001, OxFFFF, OxFFFF, OxFFFF, OxFFFF 
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APPENDIX G SSL SPECIFICATION 


| tao 2-99 ee = = = = = 5 = == 
file: psdl.as.ssl 

purpose: abstract syntax for psdl editor 

author: laura j. white 

date: 14 nov 89 


root psdl_ components; 
list psdl_ components; 


psdl_ components 
Psd1Nil () 
| PsdlPair(component psdl_ components) 


td 


component 

: NoComponent () 

Data(id type _ spec type _impl) 

Op (id operator spec operator_impl) 


=e — << ° 


id 
IdNull () 
Id (IDENTIFIER) 


=e =~ 9 


operator spec 
> OpSpec (optional interface optional _ keywords optional description 
optional axioms) 


type spec 
TypeSpec (optional type declarations optional operators 
optional keywords optional_description optional axioms) 


optional list optional operators; 
optional operators 
: OpListNil () 
| OpList (type_op_spec optional_operators) 
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type_op_spec 


° 
td 


TypeOpNil () 
TypeOpSpec (id operator spec) 


optional list optional interface; 
optional interface 


* 
e 
Sd 


InterFaceNil () 
InterFaceList (attribute optional _ interface) 


optional optional requirements; 
optional requirements 


es 
| 
. 
tf 


Reqmt sTraceNone () 
Reqmt sPrompt () 
Reqmt sTrace (id list) 


optional optional keywords; 
optional keywords 


° 
° 
t 


KeyWordsNone () 
KeyWordsPrompt () 
KeyWords (id_list) 


optional optional description; 
optional description 


° 
Sd 


InformalDescNone () 
InformalPrompt () 
InformalDesc (text) 


optional optional axioms; 
optional axioms 


: 
| 
| 
e 
e 


FormalDescNone () 
FormalPrompt () 
FormalDesc (text) 


attribute 


e 
| 
| 
| 
| 
| 
| 
e 

Sf 


EmptyAttr () 

Input (input optional requirements) 

Output (output optional _ requirements) 

States (state optional requirements) 

Generic (generic optional requirements) 

Exceptions (exception optional requirements) 

TimingInfo (optional met optional _mcp optional_mrt optional requirements) 
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’ 
ow 
He. * 


input 
Input TypeDecl (type _decl more_optional type declarations) 


output 
: OutputTypeDecl (type _decl more_optional_ type declarations) 


ry 
f 


state 
StateTypeDecl (type decl more optional type declarations 
exp optional exp_ list) 


generic 
GenericTypeDecl (type _decl more optional type declarations) 


exception 
ExceptionList (id_list) 


optional optional met; 
optional met 
MetNone () 
| MetPrompt () 
| Met (time) 


e 
f 


optional optional mcp; 
optional _mcp 
McpNone () 
{| McpPrompt () 
| Mcp (time) 


» 
f 


optional optional mrt; 
optional mrt 

: MrtNone () 

{ MrtPrompt () 
} Mrt (time) 


time 
Time (integer optional unit) 


e 
e 
s 

? 





integer 
: IntegerNil () 
i Integer (INTEGER) 


& 
f 
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optional optional unit; 
optional unit 
: UnitNil () 
| UnitPrompt () 
| UnitMs () 
| UnitSec () 
| UnitMin () 
| UnitHrs () 
4 


type decl 
TypeDecl(id_ list type _ name) 


° 
° 
° 

a 


optional list more_optional type declarations; 

more optional type declarations 
: MoreDeclListNil () 
| MoreDeclList (more type _decl more optional type declarations) 
t 


more _ type decl 
>: MoreDeclNil () 
| MoreTypeDecl (id list type_name) 


° 
v 


optional list optional type declarations; 
optional type declarations 

: OptDeclListNil () 

| OptDeclList (opt_type_decl optional type declarations) 


opt type decl 
: OptDeclNil () 
| OptTypeDecl (id list type name) 


Fist. idalist; 

dels St 

: IdNil() 

IdPair(id id list) 


=e — a 


type _ name 
TypeName (id optional generic actuals) 


e 
e 
« 
LA 
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optional optional generic_actuals; 
optional generic actuals 
GenActualNil () 
|} GenActualPrompt () 
| GenActual (type decl more optional type declarations) 


. 
tA 


operator impl 
OpImp1 () 
| OpImp1Psdl (diagram optional_streams optional timers 
optional _control_constraints optional description) 
| OpImplAda (id text) 


® 
f 


type_impl 
: TypeImp1 () 
| TypeImplOp (type name optional operator implementations) 
{| TypeImplAda (id text) 


f 


optional list optional _ operator implementations; 
optional operator implementations 
TypeListNil () 
| TypeList (type op impl optional operator implementations) 


° 
f 


type op impl 
>: TypeOpiImp1Nil () 
{| TypeOpImpl (id operator imp1l) 


e 
f 


diagram 
Diagram(link optional links) 


optional list optional links; 
optional links 
>: LinkListNil () 
| LinkList (opt_link optional links) 


e 
tA 


opt_link 
Opt LinkNil () 
OptLink (id id optional time id) 


™@e — ee 


link 
Link(id id optional time id) 
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optional optional time; 
optional time 

>: OptTimeNil () 

| OptTimePrompt () 
| OptTime (time) 


optional optional streams; 
optional streams 
: StreamsNil () 
{| StreamsPrompt () 
|} Streams (type _decl more optional type declarations) 


tf 


optional optional timers; 
optional timers 

:; TimersNil () 

| TimersPrompt () 
| Tamers (id list) 


optional optional control _ constraints; 
optional control constraints 
>: ControlNil () 
| ControlPrompt () 
| Control(constraint optional constraints) 


’ 
constraint 


: Constraint (id optional _ triggers optional_period optional finish 
constraint options) 


™e 


optional list optional constraints; 

optional constraints 
; OptConNil () 
| OptConList (optional constraint optional _ constraints) 
a 


optional constraint 
; OptConstraintNil () 
| OptConstraint (id optional triggers optional period optional finish 
constraint_options) 


=e 


optional optional triggers; 
optional triggers 
: TriggersNone () 
| TriggersPrompt () 
} TriggersChoice (triggers choice) 


=e 
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triggers choice 
TriggerChoiceNil () 
| Triggers (trigger) 
| TriggersIf (opt_trigger predicate optional requirements) 


° 
f 


trigger 
TriggerNil () 
| AllTrigger (id list optional _requirements) 
| SomeTrigger(id_ list optional_requirements) 


e 
f 


optional opt_trigger; 
opt_trigger 
Opt TriggerNil () 
| OptTriggerPrompt () 
| OptAllTrigger (id_list) 
| OptSomeTrigger (id_list) 


e 
f 


optional optional period; 
optional period 
: PeriodNone () 
| PeriodPrompt () 
| Period(time optional requirements) 


optional optional finish; 
optional finish 
: FinishNone () 
| FinishPrompt () 
| Finish(time optional_requirements) 


optional list constraint options; 
constraint_options 

>: ConListNone ({) 

| ConListOpts(con_opts constraint_options) 


e 
f 


con_opts 
: ConOptsNil () 

| OptOutput (id_list predicate optional_requirements) 

| OptException(id optional _ predicate optional _ requirements) 

| OptTimer (timer operation id optional_predicate optional_requirements)| 





{ 
I} 
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timer operation 
> OptNil () 


| Read () 
| Reset () 
|} Start () 
| Stop () 
predicate 


> Predicate(relation optional boolean relations) 


e 
e 
Ud 


optional optional predicate; 
optional predicate 
: OptPredicateNil () 
| OptPredPrompt () 
| OptPredicate (relation optional boolean_ relations) 
td 


relation 
: RelNil () 
| RelSimple (simple expression) 
| RelComplex(simple expression relational operator simple expression) 
a 


boolean relation 

: BoolNone () 

| AndRel (relation) 
| OrRel (relation) 


optional list optional boolean relations; 
optional boolean relations 
: RelListNil () 
| RelList (boolean_relation optional _boolean_relations) 


simple expression 
: SimExpNil () 
| SimInt (sign integer optional _ unit) 
| SimReal (sign real) 
{| SimId (id) 
| SimNotId (id) 
| SimString (string) 
| SimPred (predicate) 
| SimNotPred (predicate) 
{| SimTrue () 
| SimFalse () 
| SimNottTrue () 
| SamNotFalse () 
tf 
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optional list optional exp list; 
optional exp list 
ExpListNil () 
| ExpList (optional _exp optional _exp_list) 


° 
f 


optional exp 
Opt ExpNil () 
| OptExpConst (constant) 
| OptExpId (id) 
| OptExpComplex (type name id exp optional exp list) 


exp 
: ExpNil () 
{ ExpConst (constant) 
| ExpId (id) 
| ExpComplex (type name id exp optional exp list) 
string 
; String (text) 
text 
>: Text (id) 
sign 
>: SignNil () 
| Sign(SIGN) 
real 
; RealNil () 


| P Real (PREAL) 


relational operator 
> Rel None () 
| Rel_Lt() 
| Rel_Gt() 
| Rel_Eq() 
| Rel Ne() 
|) Retco) 
| Rel_Lte() 
| Rel Gte() 


? 


216 











constant 


: 
| 
| 
| 
« 
4 


ConstNone () 
ConstInt (integer) 
ConstReal (real) 
ConstTrue () 
ConstFalse () 
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APPENDIX H SSL SPECIFICATION 


[ ®e2 o-oo ee 
file: psdl.up.ssl 

purpose: unparsing rules for psdl editor 

author: laura j. white 

date: 14 nov 89 


psdl_ components 


PsdlNil [@:] 
| PsdlPair [@:"["%n"] 7] 
component 
NoComponent [~:"%sn[component]"] 
| op [~:"%nOPERATOR "*~7] 
| Data [sent Vere a 
id 
IdNull [@::="<identifier>"] 
feta [@::=7] 


e 
ff 


operator spec 


: OpSpec [~:"%nSPECIFICATION%t"****"%b%nEND"] 
type spec 
TypeSpec [“:"%nSPECIFICATION%t"* ~~" ~ "%Sb%¢nNEND" ] 


operator impl 


OpImp1l [@:"%n[operator implementation] "] 
| OpImpl1Psdl [@: "$nIMPLEMENTATIONSt "****~* "%b%nEND"] 
| OpImplAda [@:"%nIMPLEMENTATION ADA "“"%t%n{ """ }%b%nEND"] 
type _impl 
TypeImpl [@:"%n[type implementation] "] 
| TypeImploOp [@:"%nIMPLEMENTATIONSt $n" ~ ~"$b%nEND" J 
| TypeImplAda [@:"%nIMPLEMENTATION ADA "“"%t%n{ """ }%b%nEND"] 


e 
tf 
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optional operators 


e 
e 


OpListNil 
OpList 


type op spec 


e 
t 


TypeOpNil 
TypeOpSpec 


optional interface 


e 
e 


InterFaceNil 
InterFaceList 


optional requirements 


° 
dl 


Reqmt sTraceNone 
Reqmt sPrompt 
Reqmt sTrace 


optional keywords 


° 
td 


KeyWordsNone 
KeyWordsPrompt 
KeyWords 


optional description 


e 
e 


InformalDescNone 
InformalPrompt 
InformalDesc 


optional axioms 


e 
e 


FormalDescNone 
FormalPrompt 
FormalDesc 


attribute 


EmptyAttr 
Input 

Out put 
States 
Generic 
Exceptions 
TimingInfo 


{@: 
{@: 


(4s 


{@: 
{@: 


{@: 
{@: 
[@: 


[@: 
[@: 
{@: 


(@: 
(@: 
{@: 


(@: 
[@: 
(@: 


[eee 
[7 
3 
[2 
[7 
(er: 


J 
~ (een) 


"$n{optional operator}"] 


:"SnOPERATOR "~~] 


~(]@] 


] 
"$n{requirements}"] 
"$nBY REQUIREMENTS $&t $n" ~"%b" J 


] 
"tn{keywords}"] 
"SnKEYWORDS%t $n" "$b" ] 


] 
"%$n{description}"] 
"SnDESCRIPTIONSt$n{"~"} Sb") 


] 
"tn ({axioms}"] 
"SnAXIOMSSt n{"~"} Sb") 


"S$n{interface}"] 


"Sn INPUT" * "SE "7 "Sb" ] 


"SnNOUTPUT" "SE "7 "S$H") 
"SnSTATES"™~ "St" "Sb"] 


> "$nGENERIC*” "%t"" "$b" J 


"SnEXCEPTIONSSt tn"~* “ "bp" J 
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input 


output 


state 


: StateTypeDecl 


° 
a 


generic 


™e ee 


exception 


: ExceptionList 


. 
td 


optional met 
>: MetNone 
| MetPrompt 
| Met 
td 


optional mcp 
McpNone 
| McpPrompt 
| Mcp 


° 
e 


optional mrt 


= MrtNone 
| MrtPrompt 
| Mrt 
time 
: Time 
; 
integer 


>: IntegerNil 
| Integer 
; 


optional unit 


: UnitNil 
| UnitPrompt 
| UnitMs 


Input TypeDecl 


Out put TypeDecl 


GenericTypeDecl 


[“3:"St3n""""Sb"] 


[7 "Sten 77 "Sb"] 


[~:"St¥n"* “"SnINITIALLY&n" ~*~ "$b"] 


[7 "StSn"-7"Sb"] 


[@:] 
[@:"%n{met}"] 
[@:"%nMAXIMUM EXECUTION TIME "~] 


[@:] 
[@:"Sn{mcep}"] 
[@:"%nMINIMUM CALLING PERIOD "*] 


[@:] 
[@:"$n{mrt}"J 
[@:"%nMAXIMUM RESPONSE TIME "~] 


[@::="<integer>"] 
[@: s=° 


[@:] 
(@:" {units)"™] 
[@:" MS"] 
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| UnitSec [@ 


{| UnitMin [@ 

| UnitHrs [@ 
type decl 

TypeDecl [i 


e 
tf 


obo | 
>" MIN") 
>" HOURS") 


more optional type declarations 


MoreDeclListNil [@ 
| MoreDeclList [@ 


e 
a 


more type decl 
MoreDeclNil [* 
| MoreTypeDecl [~ 


e 
e 


optional type declarations 


OptDeclListNil [@: 


| OptDeclList [@ 


e 
e 


opt _type decl 
OptDeclNil [~ 
| OptTypeDecl [~ 


e 
a 


id list 


IdNil [@: 


) IdPair [@ 


° 
¢ 


type_name 


TypeName [7% 


® 
A 


optional generic actuals 


GenActualNil [@: 
! GenActualPrompt' ([@: 


| GenActual [@ 


e 
of 


J 
>7~[]@) 


>", %n{more type decls)"] 


s, tne 4 : *-) 


>~(",")@) 


:"n{optional type decl)}"] 
ehWant* a : one 


:=) 


som" (", %)@) 


] 


" {generic actual parameters}"] 
secu Shame) °) 


optional operator implementations 


TypeListNil [@ 
| TypeList [@ 


e 
¢ 


type_op impl 
TypeOpiImp1Nil [~ 


>] 
>~[)@) 


>"%n{operator implementation) "] 
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| TypeOpimpl 


e 
§ 


diagram 
Diagram 


optional links 
LinkListNil 
| LankList 


se 
iA 


opt link 
>: OptLinkNil 
| OptLink 


link 
Link 


optional time 
: OptTimeNil 
| OptTimePrompt 
| OptTime 


° 
td 


optional streams 
StreamsNil 
| StreamsPrompt 
| Streams 
a 


optional timers 
TimersNil 
| TimersPrompt 
| Timers 


e 
f 


[7:"SnOPERATOR "**] 


[~:"SnGRAPH$t%n"*""Sb"] 


[@:] 
(@:7"(]@] 


[“:"$n{optional link}"] 
Do "Sn Se | 


(os ee SES 


[@:] 
(@:" {time} "] 
(Oe 


[@:] 
[@:"%n{data stream}"] 
[@:"%nDATA STREAM$t%n"**"Sb"] 


(@:] 
[@:"$n{timer}"] 
(@:"S$nTIMERSt $n" "Sb"] 


optional control constraints 


ControlNil 
| ControlPrompt 
| Control 


e 
a 


constraint 
Constraint 


optional constraints 
OptConNil 


[@:] 
[@:"%n{control constraints}"] 
[@:"%nCONTROL CONSTRAINTS%t"* “"%b"] 


[“:"SnOPERATOR St eae etb") 


[@:] 
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* 
g 


OptConList 


optional constraint 


e 
f 


OptConstraintNil 
OptConstraint 


optional triggers 


trigger 


, 
trigger 


° 
f 


opt tri 


e 
® 
fd 


TriggersNone 
TriggersPrompt 
TriggersChoice 


s choice 
TriggerChoiceNil 
Triggers 
TriggersIf 


TriggerNil 
AllTrigger 
SomeTrigger 


gger 
OptTriggerNil 


OptTriggerPrompt 
OptAllTrigger 
Opt SomeTrigger 


optional period 


° 
? 


PeriodNone 
PeriodPrompt 
Period 


optional finish 


¢ 
® 


e 
¢ 


FinishNone 
FinishPrompt 
Finish 


constraint options 


e 
e 


ConListNone 
ConListOpts 


(@ 


[3 
[es 


[@: 
[@: 
[@: 


[@: 
a 
(@: 


[@: 
[@: 
[@: 


[@: 
[@: 
[@: 
[@: 


[G; 
[@: 
[@: 


[@: 
[@: 
[@: 


[@: 
[@: 


~()@] 


J 
"S$nNOPERATOR %t""~*~~* nop) 


] 
"“$n{triggers)"] 
"S$nTRIGGERED "~] 


"(trigger choice] "] 


-" TM 85] 


"(trigger]"] 
"BY ALL "**] 
"BY SOME "*7] 


) 

"{trigger by) "] 
ERY ALLa™ ] 

"BY SOME ""] 


] 
"%n (period) "] 
"SnPERIOD "*~] 


J 
"S$n{finish within) "] 
"SnFINISH WITHIN ""7] 


] 
~(1@] 
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con opts 
: ConOptsNil 

} OptOutput 

| OptException 

| OptTimer 


timer operation 
: OptNil 

| Read 

i Reset 

} Start 

| Stop 


td 


predicate 
Predicate 


 e ee 


optional predicate 
OptPredicateNil 
| OptPredPrompt 
| OptPredicate 


e 
e 


relation 

>: RelNil 

| RelSimple 
| RelComplex 


boolean relation 
: BoolNone 
| AndRel 

| OrRel 


[~:"%n{constraint options}"] 


(~:"$nOUTPUT "7" TE] 
[“:"%nEXCEPTION "**7] 
[> : Shree) 


[@:"(timer operation] "] 
[@:"READ TIMER"] 
[@:"RESET TIMER"] 
(@:"START TIMER"] 
[@:"STOP TIMER"] 


(@:] 
(@:" {IF predicate} "] 
fe." LF mae 


[@:"{relation]"] 
[@: 7] 
[Q@:"%t%n"""" "Fb" 


[“:" {boolean relation} "] 
[~:" AND "7] 
(7:" OR wi 


optional boolean relations 


: RelListNil 
| RelList 


simple expression 
>: SimExpNil 
[| SimInt 
| SimReal 
| SimId 

| SimNotId 

| SaimString 

| SimPred 

| SimNotPred 


[@:] 
[@:" 7] 


[@:"[simple expression]"] 
(@:°" 7] 

(@:° "J 

(@: 7] 

[Ge "NOT =) 

[@:7] 

[@: 7] 

fe: "NOT "*) 
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SimTrue 
SimFalse 
SimNotTrue 
SimNotFalse 


optional exp list 
ExpListNil 
| ExpList 


e 
ta 


optional exp 
Opt ExpNil 
| OptExpConst 
| OptExpId 
| OptExpComplex 


exp 
: ExpNil 
| ExpConst 
} ExpId 
| ExpComplex 


string 
>: String 


o 
v 


text 
Text 


sign 
: SignNil 
} Sign 


real 
> RealNil 
} P_Real 


e 
‘ 


relational operator 
Rel None 

Rel Lt 

Rel Gt 

Rel Eq 

Rel Ne 

Rel Co 

Rel Lte 


[@: 
[@: 


[- 


[7 
[7 


[@: 
[@: 
[@: 
[@: 


[@: 
[Gi : 


[@: 
[@: 


> "TRUE" ] 
> "FALSE" ] 
>"NOT TRUE" ] 
:"NOT FALSE"] 


“(1@) 


2", t%n{exp}"] 

Soon” | 

of ene ) 

sue, Ohi ee en (oO) bial | 


"[exp]"] 
~) 
~) 


aS. Santa. eS | 


:@) 


:="<gign>"] 


7) 


:="<real>"] 


:=Q] 


[relational operator) "] 
<a) 
= oI 
= ") 
j= *) 
5 Ace) 
<= ") 
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° 
f 


Rel Gte 


constant 


ConstNone 
ConstIint 
ConstReal 
ConstTrue 
ConstFalse 


[@: 


[@: 
7 J 
[@: 
{@: 
[@: 


">= "] 


"[constant]"] 
~] 

"TRUE" J 
"FALSE" ] 
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file: 
purpose: 
author: 
date: 


IDENTIFIER: 
WHITESPACE: 
INTEGER: 
PREAL: 
SIGN: 


APPENDIX I SSL SPECIFICATION 


psdl.lex.ssl 

lexical rules for psdl editor 
laura j. white 

13 nov 89 


IdentLex< [a-zA-Z] [a-zA-Z_0-9]* >; 
WhitespaceLex< [ 0 >; 

IntegerLex< [0-9]* >; 

PRealLex< [0-9}]*"."[0-9]* >; 
SignLex< [-+] >; 
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APPENDIX J SSL SPECIFICATION 


| *-------------- - - - eee 
file: psdl.ad.ssl 

purpose: attribute declarations for psdl editor 
author: laura j. white 

date: 13 nov 89 

Ident {synthesized id t;}; 

Fd Fist {synthesized id list t;}; 
PSDL_ sign {synthesized sign t;}; 
PSDL int {synthesized integer t;}; 
PSDL real {synthesized real t;}; 

id ~ Ident .t; 

id list © iG getsent, 

sign ~ PSDL_sign.t; 

integer " ESD int «o.- 

real ~ PSDL_real.t; 
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APPENDIX K SSL SPECIFICATION 


[*o---------- - -- - - - - - - - - = $= 5 ee 5 + +--+ +--+ +--+ 
file: psdl.ci.ssl 
purpose: concrete input syntax for psdl editor 
author: laura j. white 
date: 13 nov 89 
eee ee a oe en ee ea a a * / 
Ident s= (IDENTIFIER) 

{Ident.t = Id (IDENTIFIER); }; 
Id list ::= (Ident) 

{Id_list.t = (Ident.t::IdNil) ;) 

} (Ident ’,’ Id_list) 

{Id_ list$l.t = (Ident.t::Id_list$2.t);}; 
PSDL_ sign := (SIGN) 

{PSDL_sign.t = Sign (SIGN) ;}; 
PSDL_int ::= (INTEGER) 

{PSDL_ int.t = Integer (INTEGER) ; }; 
PSDL_ real ::= (PREAL) 


{PSDL_ real.t = P_Real(PREAL) ; ); 
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APPENDIX L SSL SPECIFICATION 


[| een nn ne =e 
Eile: psdl.tt.ssl 

purpose: template transformations for psdl editor 

author: laura Jj. white 

date: 12 nov 89 


= Se Se ee ee ee es ee ee ee ee ee ee ee ee ee ee es ee ee es ee ee ee ee ee ee ee es es ee ee ee es ee ee ee te ee ee ee ee ee ee es es ee ee es ee ee ee ee ee ee ee ee ee ee ee ee 


transform component 


on "type" 
<component> : 
Data (<id>,<type_ spec>,<type impl>), 


on "operator" 
<component> ;: 
Op (<id>,<operator_spec>,<operator_impl>); 


transform type op_spec 


on "enter operator" 
<type op_spec> 
TypeOpSpec (<id>,<operator_ spec>); 


transform attribute 


on "input" 
<attribute> : 
Input (<input>,<optional_ requirements>), 


on "output" 
<attribute> :; 
Output (<output>, <optional requirements>), 


on "states" 
<attribute> ;: 
States (<state>,<optional requirements>), 


on "generic" 
<attribute> ; 
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Generic (<generic>,<optional requirements>), 


on "exceptions" 
<attribute> : 
Exceptions (<exception>, <optional_ requirements>), 


on "timing info" 
<attribute> : 
TimingInfo (<optional_met>,<optional_mcp>, <optional mrt>, 
<optional_ requirements>) ; - 


transform more type decl 


on "enter type declaration" 
<more type decl> ; 
MoreTypeDecl (<id_list>, <type_ name>) ; 


transform opt_type_ decl 


on "enter type declaration" 
<opt_type decl> ; 
OptTypeDecl (<id_ list>, <type_ name>) ; 


transform optional generic actuals 
on "enter generic actual parameters" 
<optional_ generic actuals> : 
GenActual (<type_decl>,<more_ optional type declarations>) ; 


transform optional requirements 
on "enter requirements" 
<optional requirements> : 
Reqmt sTrace (<id_ list>); 
transform optional keywords 
on "enter keywords" 
<optional keywords> : 
KeyWords (<id_list>) ; 
transform optional description 
on "enter description" 


<optional description> : 
InformalDesc (<text>) ; 
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transform optional _ axioms 


on “enter axioms" 
<optional axioms> ; 
FormalDesc (<text>) ; 


transform optional time 
on "enter time" 
<optional time> : 
Opt Time (<time>) ; 
transform optional _ met 
on, “enter ME Te 


<optional_ met> 
Met (<time>) ; 


transform optional _mcp 


on Sente range 
<optional mcp> : 
Mcp (<time>) ; 


transform optional _mrt 
on -enrer MRIS 


<optional mrt> 
Mrt (<time>) ; 


transform optional unit 


on "milliseconds" 
<optional_unit> 
UnitMs(), 


on "seconds" 
<optional_unit> 
UnitSec(), 


on “minutes" 
<optional_unit> 
UnitMin(), 


on "hours" 
<optional unit> : 
UnitHrs(); 
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transform optional requirements 


on "enter requirements" 
<optional requirements> :; 
Reqmt sTrace (<id_ list>); 


transform optional streams 


on "enter streams" 
<optional streams> : 
Streams (<type decl>, <more_ optional type declarations>) ; 


transform optional timers 


On "enter timers” 
<optional_timers> : 
Timers (<id_list>); 


transform optional _ control constraints 


on "enter control constraints" 
<optional _control_constraints> : 
Control (<constraint>, <optional_constraints>) ; 


transform optional constraint 


on "enter constraint" 
<optional constraint> : 
OptConstraint (<id>, <optional_triggers>,<optional_ period>, 
<optional finish>, <constraint_ options>) ; 


transform operator impl 


on “psdl_ implementation" 
<operator_impl> : 
OpImp1Psdl1 (<diagram>, <optional_streams>,<optional_ timers>, 
<optional_control_constraints>,<optional description>), 


on “ada implementation" 


<operator_impl> :; 
OpImplAda (<id>, <text>) ; 


233 


transform type impl 


on “"psdl_implementation" 
<type imple: 
TypeImp1l0Op (<type_name>,<optional_operator implementations>), 


on "ada implementation" 
<type_ impl> ; 
TypeImplAda (<id>, <text>) ; 


transform optional triggers 


on "enter triggers" 
<optional_ triggers> : 
TriggersChoice (<triggers_ choice>) ; 


transform triggers choice 


on "simple triggers" 
<triggers_choice> : 
Triggers (<trigger>), 


on "triggers with if predicate” 
<triggers choice>: 
TriggersIf (<opt_trigger>,<predicate>,<optional requirements>) ; 


transform trigger 


on "all" 
<trigger> : 
AllTrigger (<id_list>,<optional_ requirements>), 


on "some" 
<trigger> ; 
SomeTrigger (<id_list>,<optional_ requirements>) ; 


transform opt _ trigger 


on "all" 
<OpLTcErgqger> = 
OptAllTrigger (<id_list>), 


on "some" 


<Opreerrgger> 
OptSomeTrigger (<id_list>); 
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transform optional period 


on “enter period" 
<optional period> ; 
Period (<time>,<optional_ requirements>) ; 


transform optional finish 


on “enter finish within" 
<optional finish> 
Finish (<time>, <optional requirements>) ; 


transform con_opts 


on "output" 
<con_opts> : 
OptOutput (<id_ list>,<predicate>,<optional_requirements>), 


on “exception" 
<con_opts> : 
Opt Exception (<id>, <optional_predicate>,<optional_requirements>), 


on "timer" 
<con_opts> ; 
OptTimer (<timer_operation>, <id>, <optional_ predicate>, 
<optional requirements>) ; 


transform optional predicate 
on "enter predicate" 
<optional _ predicate> : 
OptPredicate (<relation>,<optional boolean _relations>) ; 
transform timer operation 
on "read timer" 


<timer operation> 
Read (), 


on “reset timer" 
<timer operation> :; 
Reset (), 


on “start timer" 


<timer operation> 
Start (), 
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On "Stop Ener” 
<timer operation> : 
Stop (); 


transform relation 


on “simple" 
<relation> ; 
RelSimple (<simple expression>), 


on "complex" 
<relation> : 
RelComplex (<simple_expression>,<relational_operator>,<simple express 





transform simple expression 


on Jinteqersexc. 
<simple expression> : 
SimInt (<sign>, <integer>,<optional_unit>), 


on “real lex. 
<simple expression> : 
SimReal (<sign>,<real>), 


on “ad expe 
<simple expression> ; 
SimId(<id>), 


on "not_id_ exp" 
<simple_expression> : 
SimNotId(<id>), 


on “string exp" 
<simple expression> ; 
SimString(<string>), 


on "predicate exp" 
<simple expression> : 
SimPred(<predicate>), 


on "not predicate exp" 
<simple expression> ; 
SimNot Pred (<predicate>), 
on "true" 
<simple expression> : 


SimTrue (), 


on "not true" 
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<simple expression> 
SimNotTrue(), 


on Afialse™ 
<simple expression> ; 
SimFalse(), 


on "not false" 
<simple expression> ; 
SimNot False () ; 


transform relational operator 


one "<" 
<relational operator> : 
Rel Lt(), 


on "<=" 
<relational_operator> 
Rel Lte(), 


on, Se" 
<relational_ operator> 
Rel Gt(), 


on ">=" 
<relational_operator> ; 
Rel Gte(), 


on "=" 
<relational_operator> 
Rel_Eq(), 


on o/h 
<relational_operator> : 
Rel Ne(), 


on,**'4" 
<relational_operator> : 
Rel Co(); 

transform exp 

on "constant" 
<exp> : 
ExpConst (<constant>), 

on "id*® 


<exp> 3; 
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ExpId(<id>), 


on "complex" 
<exp> : 
ExpComplex (<type_name>, <id>,<exp>,<optional_exp list>); 


transform optional exp 


on "constant" 
<optional exp> : 
OptExpConst (<constant>), 


on "id" 
<optional_exp> ; 
Opt Expid(<id>), 


on "complex" 
<optional _exp> : 
Opt ExpComplex (<type_name>, <id>,<exp>,<optional_ exp list>); 


transform constant 
on "integer" 
<constant> ; 
ConstIint (<integer>), 
on "real" 
<constant> : 
ConstReal (<real>), 
on "true" 
<constant> : 
ConstTrue(), 
on "false" 
<constant> : 
ConstFalse () ; 
transform opt_link 
on "enter Links 
<Opeolinke « 
Opt Link (<id>, <id>, <optional _time>,<id>) ; 


transform type op _impl 


on “enter operator implementation" 
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<type_op impl> 
TypeOpImp1l (<id>,<operator impl>); 


transform boolean_relation 
on "and relation" 
<boolean_relation> : 
AndRel (<relation>), 
on "or relation" 


<boolean_relation> : 
OrRel (<relation>) ; 
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APPENDIX M KODIYAK TRANSLATOR SPECIFICATION 


File: translator.k 
Author: charlie altizer 
Date: dec 88 


Last Modified: dec 89 by laura j. white 


—_ ome oom —_ = oo 


'definitions of lexical classes 


define Digit t0=3)) 

define Int > {Digit }+ 

define Letter :[a-zA=Z ) 

define Alpha : ({Letter} | {Digit }) 
define Blank >{ \nj 

%define Char ir. hel 

define Quote om fuel 


! definitions of white space 
:{Blank}+ 


! definitions of compound symbols and keywords 


GTE 7 ">=" 

LTE 7 t<=" 

NEQV ¢u/=n 

ARROW 2 

TYPE :type|TYPE 

OPERATOR :operator|OPERATOR 

SPECIFICATION :specification|SPECIFICATION 

END :end|END 

GENERIC :generic|GENERIC 

INPUT :input | INPUT 

OUTPUT :output | OUTPUT 

STATES >States|STATES 

INITIALLY :initially| INITIALLY 

EXCEPTIONS :exceptions | EXCEPTIONS 

NORMAL :normal : NORMAL 

MAX EXEC TIME :maximum[ )Jexecution[ ]time|MAXIMUM[ ])EXECUTION[ ] TIME 
MAX RESP TIME :maximum[{ )response[ )time|MAXIMUM[ ])RESPONSE[ ) TIME 


MIN CALL PERIOD :minimum[ ])calling[ )period|MINIMUM[ ])CALLING[ ] PERIOD 
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MICROSEC smicrosec |MICROSEC 

MS :ms |MS 

SEC :sec|SEC 

MIN smin|MIN 

HOURS :hours | HOURS 

BY :by{ )requirements|BY[ ])REQUIREMENTS 
KEYWORDS > keywords | KEYWORDS 

DESCRIPTION :description|DESCRIPTION 
AXIOMS :axioms |AXIOMS 

IMPLEMENTATION :implementation]| IMPLEMENTATION 
ADA :ada|Ada|ADA 

GRAPH :graph|GRAPH 


DATA_STREAM 
TIMER 


sdata[ )stream|DATA[ )STREAM 
:timer | TIMER 


CONTROL scontrol[ )constraints|CONTROL[ )CONSTRAINTS 
TRIGGERED striggered|TRIGGERED 

ALL sby{ Jall|BY[ ])ALL 

SOME :by{ )some|BY[ ] SOME 

PERIOD :period| PERIOD 

FINISH :finish[ )within|FINISH[ ])WITHIN 
EXCEPTION :exception | EXCEPTION 

READ :read[ )timer|READ[ ])TIMER 

RESET :reset[ )timer|RESET[ ] TIMER 
START sstart[ )timer|START[ ] TIMER 
STOP :stop[ )timer|STOP[ ] TIMER 

IF :if|IF 

NOT a55 " | net *'|"*NOT* 

AND >"&"( "and" | "AND" 

OR al ior (\*OR* 

TRUE strue|TRUE 

FALSE :false|FALSE 

ID : {Letter} {Alpha} * 


STRING LITERAL 


: {Quote} {Char} * {Quote} 


INTEGER LITERAL : {Int} 


REAL LITERAL 
TEXT 


2{ Tnvypes {Pat } 
aU PChar) *")" 


! operator precedences 
! $left means group and evaluate from the left 


$left OR; 

S$left AND ; 

left NOT; 

Sleft '’<', '>’, ‘=’, GTE, LTE, NEQV; 
S$left teiges 

%% 
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! attribute declarations for nonterminal symbols 


start { trn: stuing-s 
psdl { trn: string; 
uncond output_map:string->string; 
out_env:string->string; 
in env: string->seriaey |; 
component { trn: string; 
uncond_ output map in:string->string; 
uncond_ output_map_ out:string->string; 
in env: string->string; 
out env:string->string; }; 


data type { tren.sstring, 
in @nvs String=-s tang; al, 
operator { trn: string; 
uncond_output_map_in:string->string; 
uncond output map out:string->string; 
in @nv:Sering=-strLing, 
out @6nv /Stcing. stenng ; aly 


type spec { trn: string; 

in env: string->string a), 
type decl 1 list { trn: string; 

in env: SELINGS-St rang: se, 

type decl { trn: string; 

in _env,out_env :string->string; 

opid: string; 

action _code:string; 

ucond output:string; }; 


op spec 0 list { trn: string; 
in env: SCring=>Sstring sae 


operator spec { opid:string; 
ds_decl: string; 
Statendee! string, 
ucond output :string; 
excp_decl:string; 
in env, out veny String >-sening; |} 


interface { in env,out env :string->string; 
in parm, out_parm : string; 
ds decl: string; 
State deci strang, 
excp decl:string; 
ucond_output:string; 
opid: strimg,; |}, 


attribute { ds_decl: string; 
in _env,out_env :string->string; 
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in parm, out parm: string; 
opid: string; 

state decl:string; 

ucond_ output :string; 

excp decl:string; }; 


mame { trn: string; }; 

unit { value: int; }; 

id list { trn: string; 
action code:string; 
tname: string; 
opid: string; 
ucond_output:string; 


count 


Sant : 


exp env:int->string; 
in_env:string->string; 
out _env:string->string; }; 


reqmts trace { trn: string; }; 
functionality { trn: string; }; 


keywords { trn: 


string; }; 


informal desc { trn: string; }; 
formal desc { trn: string; }; 
type impl { trn: string; }; 
op_impl 0 list { trn: string; }; 
operator impl { trn: string; 


out_env:string->string; 
in_env:string->string; 


uncond output_map:string->string; 


loc_ds_decl: string; 
timer decl:string; 
opid:string; }; 


psdl_impl { trn: string; 
parent : string; 
uncond output _map:string->string; 
in_env:string->string; 
out env:string->string; 
loc_ds_decl: string; 
timer decl:string; }; 


data_ flow diagram { trn: string; 


in_env, decl_map : 


link _0 list { trn: string; 
in_env,in_decls,out_decls 


limi {eean: string; 


in_env,in_decls,out_decls 


opt_time { trn: string; }; 
type_name { trn: string; }; 
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string-> string; 


}; 


string->string; 


string->string;  } 


c 


) 


v 


timers { trn: String; 47 
control constraints { "tren: ssersng, 
parent : string; 
uncond output _map:string->string; 
in env:string->string; 
out env: string-—>string,; 
decl map : string=->string; 
}; 
constraint options { trn : string; 
in env: String—-st ring, 
out _env:string->string; 
Opid: string; 
i 
more constraints {trn : string; 
parent: string; 
uncond output _map:string->string; 
in env:string->string; 
out env: string->string,; 
decl_map : string->string; 
}? 
opt trig { out lenv: strings string, 
in_env: string->string; 
streams check: string; 
end_if streams:string; 
pred: string, 
end if pred string, 


trigger {if: string; 
end if:string; 
in_env, out_env:string->string; }; 
opt _per { trn: string; }; 
opt _fin_w { trn: string; }; 
streams {trn: string; 
in env,out_env :string->string; }; 
timer op { txrn: Strang, a), 
opt if predicate “(oie scrringe, 
end 2 £:string, 
parent :string; 
in €nv ; String=>) strane, ; 
predicate { trn: string; 
in €nv: ‘stsang=-se7 ing, 
type: string; }; 
expression list { trn: string; 
count .2ne 
exp (€nv-ant->string, | 
expression { trn: string; }; 
relation {trn: string; 
in_env: string->string; 
type: string; }; 
simple expression { trn: string; 
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| parent: string; 
in_env: string->string; 
type:string; }; 
rel op {trn: string; 
left _op:string; 
right_op: string; 
opn_type: string; 
parent: string; }; 
sign {trn: string; }; 


fattrbute declarations for terminal symbols 


ID{ %*text: string; }; 

TEXT{ %text: string; }; 

STRING LITERAL{ %text: string; }; 
INTEGER LITERAL { %text: string; }; 
REAL LITERAL {%text: string; }; 


%% 
!'psdl grammar 


start 
psdl 
{ toutput (("with PSDL_SYSTEM;\nuse PSDL_ SYSTEM; \npackage TL is\n", 
psdl.trn, "end TL; \n")j}; 
psdl.in_env = psdl.out_env; 


| 


psdl 
component psdl 
{ psdl[1).trn = [component.trn,"\n",psdl1[2).trn]); 
psdl[(1].out_env = component.out_env +| psdl[2).out_env; 
psdl(ij].uncond_output_map = component.uncond_output_map out 
+| psdl[2] .uncond_output_map; 
component.in_env = psdl[1].in_env; 
component.uncond_output_map_in = psdl[2].uncond_output_map; 
psdl[(2].in_env = psdl[i].in_env ; 
} 
| 
{ psdl.trn = ""; 
psdl.out_env = {(?:string:"")}}; 
psdl.uncond_output_map = {(?:string:""}) ; 
) 
component 


data type 
{ component.trn = ""; 
component.out_env = {(?:string:""} }; 
component .uncond_output_map out = { (?sstring:"")); 
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data _type.in_env = component.in env; 


} 


| operator 
{ component.trn = operator.trn; 
component.out env = operator.out env; 
component .uncond_ output _map_out = operator.uncond output map out) 
operator.in_env = component.in_ env; 
operator.uncond_output_map_in = component.uncond output _map in; 


data _ type 
: TYPE ID type_spec type impl 
{ data typest ra 7. 
type spec.in_ env = data_type.in_env; 


} 


operator 
; OPERATOR ID operator spec operator impl 
{ operator.trn = 

(operator.in _env(ID.%text”"CONSTRUCT") == "composite operator" 

-> ["\npackage ", 
ID.%text," SPEC is\n",operator spec.ds decl,"\n", 
operator impl.loc_ds_decl,"\n", 
operator spec.state_decl,"\n", 
operator impl.timer decl1,"\n", ( 
operator spec.excp decl,"\nend ", 
ID.%text," SPEC; \n",operator impl.trn) 

# Limi! 

); 

operator.uncond output map out = 
{(ID.%text:operator spec.ucond_output) }; 


operator spec.opid = ID.%text; 

operator spec.in_ env = operator.in_ env; 

operator impl.opid = ID.%text; 

operator impl.in_env = { ("PARENT":ID.%text)} +! operator.in_ env; 
operator impl.uncond output_map = operator.uncond_ output map in; 
operator.out env = operator spec.out_ env +t] operator impl.out_eni 


type spec 
: SPECIFICATION type decl 1 list op spec 0 list functionality END 
{ type spec.trn =) ""; 
type _decl 1 list.in_env = type _spec.in env; 
op_spec_0 list.in_env = type _spec.in_env; 


} 
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eype decl 1 list 
| = /cype sdecl 
{ typesdecl 1 list.trn = type decl.trn; 
type _decl.action_code = "type"; 
type_decl.in_env = type _decl_1 list.in env; 


{type decl 1 list.trn = "";} 


type decl 
1G, list e@:’ atype name 
{ type decl.trn = id list.trn; 
type decl.out_env = id list.out_ env; 
type_decl.ucond_output = id_list.ucond_output; 
iaplist.in env = type decl.in env; 
id_list.action_code = type decl.action_code; 
id_list.tname = type name.trn; 
id_list.opid = type decl.opid; 
id list.count = 1; 
idglist.exp env = { (?:int:"") }; 


| id_ list ’:’ type_name ’,’ type decl 
{ type decl[1].trn = id list.trn ~ type decl[2).trn; 
| type decl[1].out_env = id _list.out_env +| type decl[2).out_env; 
type _decl.ucond_output = id list.ucond_ output 
~ type decl[2).ucond_ output; 


id list.in_env = type decl[1].in_env; 
id_list.action_code = type decl[1].action_code; 

id list.tname = type _name.trn; 

id list.opid = type decl[1] .opid; 

deers. count 1; 

id list.exp_env = {(?:int:"") }; 

type decl[(2].in_env = type _decl[1].in_env; 

type decl[2].opid = type_decl[1).opid; 

type _decl[2] .action_code = type _decl[1] .action_code; 


op_spec_0 list 
: op spec 0 list OPERATOR ID operator spec 
{ op_ spec 0 list[1]).trn = ""; 
operator spec.in_env = op spec 0 list.in env; 
op_spec 0 list[2]).in_env = op_spec_0_ list[1]).in_env; 


} 


{ op spec 0 list.trn= ""; } 


se 


operator spec ( 
SPECIFICATION interface functionality END 
{ operator spec.ds_ decl = interface.ds_ decl; 
operator spec.state_decl = interface.state decl; 
operator _spec.excp decl = interface.excp decl; 
operator spec.ucond output = interface.ucond output; 
operator spec.out_env = 
(interface.out_env(operator spec.opid”"INPARM") == "" || 
interface.out_env (operator spec.opid” "OUTPARM") == "" 
-> {((operator spec.opid” "PROCCALL") : 
[interface.out_env(operator_ spec.opid” "INPARM"), 
interface.out env(operator spec.opid” "OUTPARM") J) } 
# {((operator spec.opid” "PROCCALL") : 
[anterface.out_env(operator spec.opid” "INPARM"),",", 
interface.out_env(operator spec.opid” "OUTPARM") }) } 
) +| interface.out_env; 


interface.in_env = operator spec.in env; 
interface.opid = operator spec.opid; 


interface 
: interface attribute regmts trace 
{ interface[1].ds_ decl = 
[interface[2].ds_decl, "\n",attribute.ds decl]; 
interface | scate decia— 
[interface[2].state_decl,"\n",attribute.state decl]; 
interface[1].excp decl = 
Pinterrace|2)sexep decl, "\n", attribute. exepadecn |, 
interface[1].in_parm = interface[2].in_ parm ~ attribute.in parm; 
interface[1].out_parm = interface[2].out_ parm ~ attribute.out_par 





interface[1] .out_env = 
{ ((anterface[1] .opid” "INPARM") :interface[1] .in_parm) 
((interface[1] .opid” "OUTPARM") :interface[1].out_parm) } 
+| interface[2]}.out_env +] attribute out env; 


interface[1].ucond_output = interface[2].ucond_output 
~ attribute.ucond_ output; 


interface[2].opid = interface[1].opid; 
interface[2Z].in_env = interface[1] .in_env; 
attribute.in_enve= intersace( 1). ingen, 
attribute.opid = interface[1].opid; 


{interface.ds decl = ""; 
interface.state decl = ""; 
in@ertace-excprydec!] o “i, 
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interfacé.in parm = *"; 
interface.out parm = ""; 
interface.out_env = {(?:string:"") }; 
interface.ucond output = ""; 


™=¢@ 


attribute 
; GENERIC type decl 

{ type_decl.action_code = ""; 
type decl.opid = attribute.opid; 
type _decl.in_env = attribute.in env; 
attribute.out_env = type _decl.out_env; 
attribute.ds decl = ""; 
attribute.state decl = ""; 
attribute.excp decl = ""; 
attribute.in parm = ""; 
attribute.out parm may, SS Oe 
attribute.ucond output = ""; 


| INPUT type decl 

{ type decl.action_ code = "input"; 
type _decl.opid = attribute .opid; 
type _decl.in_env = attribute.in env; 
attribute.out_env = type_decl.out_env; 
attribute.ds_decl = type decl.trn; 
attribute.state decl = ""; 
attribute.excp decl = ""; 
attribute.in parm = type _decl.out_env(attribute.opid” *INPARM") ; 
attribute.out parm = ""; 
attribute.ucond output = ""; 


| OUTPUT type decl 

{ type_decl.action_code = "output"; 
type_decl.opid = attribute.opid; 
type _decl.in_env = attribute.in_ env; 
attribute.out_env = type _decl.out_ env; 
attribute.ds decl = type decl.trn; 
aetribute.state decl =r 9", 
attribute.excp decl = ""; 
attribute.in_ parm = ""; 
attribute.out parm = type decl.out_env(attribute.opid* "OUTPARM") ; 
attribute.ucond output = type_decl.ucond_output; 


| STATES id_list ‘:’ ID INITIALLY expression list 
{ id_list.action_code = "states"; 


249 


id list.opid = attribute.opid; 

id list.tname = ID. $text; 

id list.count = 22; 

id list.exp_env = expression_list.exp_env; 
id list.in_env = attribute.in env; 
expression_list.count = 1; 
attribute.out_env = id list.out_env; 
attribute.ds decl = ""; 
attribute.state_decl = id _list.trn; 
attribute-excpedec| aaa, 
attribute.in parm = ™*; 
attribute.out_parm = ""; 
attribute.ucond output = ""; 


| EXCEPTIONS id list 

{ id list.action code = Texcep™, 
id list.tname = "exception"; 
id list.opid = attribute.opid; 
id list scount =— 
id list.exp env = {(7:ines" 7); 
id list .in_ envy = 4eenibuite aneen, 
attribute.out env = id list.out_env; 
attribute, dsgdecl 2, 
attribute.state decl = ™"; 
attribute.excp decl = {id _list.trn," =: PoDL EXCEPTION; \nade 
attribute. ineparmee 
attribute.out parm = ""; 
attribute.ucond output = ""; 


| MAX EXEC TIME time 
{ attributcesdsidecie= a: 


attribute.state decl = ""; 
attribute.excp decl = ""; 
attribute.out_env =) {((?:strang: "))7 
attribute.in parm = ""; 
attribute.out_parm = ""; 


attribute.ucond output = ""; 


| MIN CALL PERIOD time 
{ attribute.ds decl = ™|; 
attribute.state deci = “"; 


attribute.excp decl = ™"; 
attribute.out_env = { (?:string:"") ); 
attribute.in_parm = ""; 
attribute.out_parm = ""; 
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attribute.ucond output = ""; 


| MAX RESP_TIME time 
{ attribute.ds decl = ""; 

attribute.state decl = f"; 
attribute.excp decl = ""; 
attribute.out_env = { (?:string:"") }; 
attribute.in parm = ""; 
attribute.out parm = ""; 
attribute.ucond output = ""; 


id list 
2= ID ’,’ id_list 
(erdilzse([i) .trni= 
(id list[1].action_code == "input" || 
id list[l) .action_code == "output" 
-> (id list[1]-.in_env(id list[1].opid”"PARENT") == "* 
-> ["package DS",ID.%text," is new ", 
(id list[1]).in_env(ID.%text°"BUFF TYPE") == "fifo" 
-> "FIFO BUFFER" 
# "SAMPLED BUFFER") 
7"(",id list[1] .tname, ");\n"] 
# (["package DS",ID.%text," renames ", 
id _list(1].in_env(id_list[1].opid”"PARENT")," SPEC.DS", 
ID.%text,";\n"]) ~ id _list[2].trn 


# id_list[1].action_code == "states" 
-> ["package DS",ID.%text," is new STATE VARIABLE (", 
id list(1].tname,", ",id_list[1].exp_env(id_ list[1].count), 
*)e\n®))) id_liet(2dytrn 


# id list[1].action_code == “excp" 
-> ["EX",ID.%text,",",id list[2].trn] 


# id list[1].action_code == "stream" 
-> ["package DS",ID.%text," is new ", 
(id list[1].in_env(ID.%text "BUFF _ TYPE") == "fifo" 
-> "F IFO_BUFFER" 
# "SAMPLED BUFFER"), "(",id list[1].tname,");\n") 
“ id _list[2].trn 


# id_list[1].action_code == "timer" 
-> [“TL",ID.%text,",",id list[2].trn) 


# id list[1].action_code == "by all" 


251 


-> [id_list[1].opid,"_ SPEC.DS",ID.%text, ".NEW_DATA"," AND \ng 
id list (2) tren) 


# id 11st|T)/-action cede == "by some" 
-> [id_list[1].opid," SPEC.DS",ID.%text,".NEW_DATA"," OR \n" 
id list (2)een) | 


# id list[1])-action code —-=—)ecemecue-ae. 
-> [id_list[1].in_env(id_ list|1].opid “PARENT") ,™ SPEC=ro a 
ID. ttext, "WRITE (",1D.%text, ) 7 (np adeltet | ete) 


de eee 


id list(2]):in envy = t0lvst (1) amen, 

id list [2] action code = 1d uihist (1) Wacticnsccae, 

id list (2])-.opid = ad) lise |[l)eepia, 

id list [2]:tname = id list U)-tnuame, 

id list[2].exp_ env = id list[1].exp_env; 

id list[2].count = id list[1].exp_env(id list/[1].count + 1) ae 
=7 id list) coung 4 
# id listi) -ccount; 


dV list PoP outmen va. 
(id list {1l])\-action code == Sb Veale 
-> {((ID.%text *"BUFF TYPE") :"fifo")} +| id_list[2].out_env 


# id_list[{1].action_code == "by some" 
-> {((ID.%text "BUFF TYPE") :“sampled")} +] id list{2] 7ouegeue 


# id list[1] .action_code == "input" 
-> {((ID.%text “"TYPE") :id list {1l)}-tname) 
((ID. text ~"CONSTRUCT") :"data_ stream") 
((id_ list [1] .opid” “INPARM") ;:[ID.%text,",", 
id list[2].out_env(id_list[2] .opid” "INPARM") }) 
y+ | 2d vst Zen gen 


# id list([1)] action code l== “cutput® 
-> {((ID.%text ""TYPE") :id_list[1].tname) 
((ID.%text ~"CONSTRUCT") :"data_stream") 
((id_list[1]cpid "OUTPARME) [te teext, ", ", 
id list[2Z] -out env (eaetise (2), copra “OUTPARM"™) ])) 
} ee) 1d erst 2) outa ny, 


# id list[1].action_ code == "stream" 
—> {((ID-stext” "“TYPE™) - idler Die ename) 
((ID.%text “"CONSTRUCT") :"data_stream")} +| id list[2].out_e 


# id_list[1].action_code == "states" 


-> {((ID.%text*"TYPE") :id list [1] .tname) 
((ID.%text “"CONSTRUCT") :"data_ stream")} +| id_list[2] .out_¢é 
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# id list[1).action_ code == "excp" 
-> {((ID.ttext~ "CONSTRUCT") :"exception")} +| id_list[2].out_env 


# id_list[1].action_code == "timer" 
-> {( (ID. %text “"CONSTRUCT") :"timer")} +] id list[2].out_env 


# id list[(1).action_code == "co output" 
-> {({id_list[1]).opid,"_ ",ID.%text, "OUTPUT"] :"conditional") } 
+| id list [2]).out env 


# {(?: string: ™") } 
); 


id _list.ucond output = 
((id_list[{1]).in_env(id list[1].opid”™" ""ID.%text “"OUTPUT") 
<> "conditional" ) && 
(id_list[1).action_code == "output") 
-> [id_list[1) .in_env(id_list[(1].opid”™ "PARENT") ,"_SPEC.DS", 
ID.%text, ".WRITE(", ID. text, ") ;\n"] 
# we 
) °° id _list[2].ucond_output; 


} ID 
{ ad 1i8t.trn = 
(id list.action_code == "input" || 
id list.action_code == "output" 
-> (id_list.in_env(id_list.opid”™"PARENT") == "" 
-> ("package DS",ID.%text," is new ", 
(id_list.in_env(ID.%text "BUFF TYPE") == "fifo" 
-> "FIFO BUFFER" 
# "SAMPLED BUFFER") 
,"(",id list.tname,");\n"] 
# ("package DS",ID.%text," renames ", 
id list.in_env(id_list.opid” "PARENT") ,"_SPEC.DS", 
ID.%text,";\n")) 


# id list.action_code == "states" 
-> ("package DS", ID.%text," is new STATE VARIABLE(", 
id list.tname,", ",id_list.exp_env(id_list.count), 
evn] 
# id list.action_code == "excp" 
-> ["EX",ID.%text] 


# id list.action_code == "stream" 
-> ("package DS",ID.%text," is new ", 
(id _list.in_env(ID.%text“"BUFF TYPE") == "fifo" 
-> "FIFO BUFFER" 
# “SAMPLED BUFFER"), "(",id_ list.tname,");\n"] 
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# 


nie! 


(id list .action_code == yea 
-> {((ID.%text* "BUFF TYPE") :"fifo") } 


# 


id list /action jcode = "timer" 
—-> ["TL", ID. %text] | 


id list.action_code == "by ali" 
-> [id_list.opid," SPEC.DS",ID.%text,".NEW DATA"] 


id list.action_ code == "by some" 
-> [id_list.opid," SPEC.DS",ID.%text,".NEW DATA"] 





id list.action code j==— “co ‘cutput™ 
-> [id_list.in_env(id_list.opid*"PARENT")," SPEC.DS", ID. %text, 
" WRITE (",ID.%text,");\n"] 


bes 


Pst. out env = 


id list.action_code == "by_some" 
—> {( (ID. Stexte*surr  TYeR*) - Ssampledayy, 


id list [1] actienvcodes==. 0 inpuc. 

-> {((ID.%text*"TYPE") :id_list[1].tname) 
((ID.%text “"CONSTRUCT") :"data_stream") 
({id_list.opid” "INPARM") :ID.%text) } 


id _ list [1] -acttengeode” =] oucpur 

—> {((ID.%text” SEYPr") (2 deeee ei erame) 
((ID.%text” "CONSTRUCT") :"data_ stream") 
( (id list .opid* "OUTPARM") :ID.%text) } 


id list{1] .action_codé (<=) "stream" 
-> (((ID.%text "Tyne ides li. tname) 
((ID.%text “"CONSTRUCT") :"data_ stream") } 


1deliSt {| (act 1onmecdes = aieaiaes. 
-> {(C(ID-%text “PYPE™) = 1divsel te tname} 
((ID.%text “"CONSTRUCT") :"data_stream") } 


id_list.action_code == "excp" 
-> {((ID.%text” "CONSTRUCT") :"exception") } 


id list.action code == "tCimer®™ 
-> {((ID.%text ~"CONSTRUCT") :"timer") } 
id list.action code == "co output” 


-> {([id_list ‘opid, "9", ID. ttexte, "OUTPUR" ]: "conditional | 


{ (?vstring. ")4 
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id list.ucond_output = 
((id_list.in env(id list.opid”™" ""ID.%text “"OUTPUT") <>"conditional") 
&& (id list.action_code == "“output") 
-> [id_list.in_env(id list.opid”"PARENT")," SPEC.DS",ID.%text, 
" WRITE(",ID.%text,");\n"] 
a 8 
3 


time 
INTEGER LITERAL unit 
{ time.trn = ""; } 
’ 
unit 
: MICROSEC 


{ unit.value = 1; 


) 


| MS 
{ unit.value = 1000; 
} 
| SEC 
{ unit.value = 1000000; 
) 
| MIN 
{ unit.value = 60000000; 
} 
{| HOURS 
{ unit.value = 3600000000; 


reqmts trace 

BY id list 

{ reqmts trace.trn = ""; 
id list.in_env = ((?:string:"") }; 
id list.action_code = ""; 
id list.tname = ""; 
id list .opid =f%; 
id list.count = 1; 
id list.exp_env = {(?:int:"")); 
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{ reqmts trace. tine ee a) 


. 
f 


functionality 
keywords informal_desc formal desc 
{ functionality.trn = ""; } 


keywords 

KEYWORDS id list 

{ keywords.trn = ""; 
id list.in env =e ( (rostring. 4, 
id last .action code (= =", 
id list.tname = ""; 
id list, opid.—=-%"; 
id list eount )— 9r, 
id list. exp envy = (oot) ee 


{ keywords.trn = ""; } 


informal desc 
: DESCRIPTION TEXT 
{ informal _desc.trn = "\n"; } 


{informal desc.trn = ""; } 


formal desc 
>: AXIOMS TEXT 
{ formal _desc.trn = "\n"; } 


{ formal deésecitrn =~ 7a) 


type _impl 
IMPLEMENTATION ADA ID END 
{ type_impl.trn = ["procedure ",ID.%text," is;\n"]; } 
| IMPLEMENTATION type name op_impl 0 list END 
{ type_impl.trn = ["\n package DATA_TYPES is \n",type_name.trn,"\n", 
Oop_impl. 0 list .trn, “\ne, 
“end, \n- 7 aa 


op. ampl 0 J1se 
op_impl_0 list OPERATOR ID operator_impl 
{ op_impl_0 list [1] (trae, 
operator _impl.opid = ID.%text; } 


256 





{op imp! Ombist [1] .trn.=.""; } 


operator impl 
: IMPLEMENTATION ADA ID END 
{ operator impl.trn = ""; 
operator impl.loc_ds decl = ""; 
operator _impl.timer decl = ""; 
operator impl.out_env = { ((ID.%text “"CONSTRUCT") :"atomic_operator") }; 
} 


| IMPLEMENTATION psdl_ impl 
{ operator impl.trn = psdl_impl.trn; 

Operator impl.loc_ds decl = psdl_impl.loc_ds decl; 
operator _ impl.timer decl = psdl_impl.timer decl; 
psdl_impl.parent = operator _impl.opid; 
psdl_impl.in_env = operator impl.in env; 
psdl_impl.uncond_output_map = operator _impl.uncond_output_map; 
operator impl.out_env = 

{ ((operator_impl.opid” "CONSTRUCT") :"composite_operator")} +] 

psdl_impl.out_env; 


=e 


psdl_impl 
; data_flow diagram streams timers control_constraints informal _desc END 

{ psdl_impl.trn = control_constraints.trn; 
psdl_impl.out_env = streams.out_env +| control_constraints.out_env; 
psdl_impl.loc_ds_decl = streams.trn; 
psdl_ impl.timer_decl = timers.trn; 
data_ flow diagram.in_env = psdl_impl.in_env; 
streams.in_env = psdl_impl.in_env; 
control _constraints.parent = psdl_impl.parent; 
control constraints.in_env = psdl_impl.in_env; 
control_constraints.decl_map = data_flow_diagram.decl_map; 
control constraints.uncond_output_map = psdl_impl.uncond_output_map; 


=e 


data flow_diagram 
GRAPH link 0 list 
{ data_flow_diagram.trn = ""; 
data flow diagram.decl_map = link_0_list.out_decls; 
link_0_ list.in_decls = {(?:string:"") }; 
link _0 list.in_env = data _flow_diagram.in_env; 


} 


link 0 list 
: link link_0O list 
(etink Oslist(1].ten =<"; 
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link 0 12St fli@ouGgedects a= link 0 list {2]).cutidecis: 
link 0 J3st(Ziernedect>s = link.out_decls; 

link.in decls = Tank 0 list [V)Sanideets, 

link. plenwe link] 0) trst {1 |-anveny, 
Jink.0 list (2) 7incenv = link_0O list [1].in_env; 


} 


{ Link (vse trne= "9, 
link 0 list .out.decis = Tinkgg™ TTS: inmaec is, 


} 


link 
ID! 235d opt_time ARROW ID 
{ link.trn = ""; 
link.out_decls = 

(link.in_decls(ID[3].%text“ID[{1].%text”"READ") == "dup" 
=o ed (2 Site Pca) a) 
# { ((ID(3).%text“"READ") : [link.in_decls(ID[3].%text“"READ"), 
link.in_env("PARENT"),"_ SPEC.DS",ID[1] .%text,".READ(",ID[1].%te 
");\n")) ((ID[(3].%text°ID[1].%text*"READ") :"dup") } 
ast 





(link.in_decls([ID[2) .ttext," ",ID[{1].%ttext]) == "dup" 
=> 71 (7: string: "")-] 
# {(ID[(2] .%text: [link.in_decls(ID[2].%text), 
ID[1] .%text,™ > ™,link.in env (ID[1l) .stexee tyros 
We\n")) ({ID[(2].ttext;™ |”, IDTL). svext ] aru aa 
| a | 


(link.in_ decls([ID[3].%text," ",ID[{1].%text]) == "dup" 
—-> {(?:string:"") } 
# {(ID(3].%text: (link.in_decls(ID[3] .%text), 
ID{1}.%text," : ",;link.in env(ID[1] -ttext “"TYPEQ)> 
Ie GS gril ||) ({ID[3)-ttext," “,ID[E1) . seext] : "dups)y) 
) + link?in decls;, 


Opt tame 
‘ 3" tame 
{ opt _time.trn LL | 


{ opt_time.trn = "\n"; } 


streams 
DATA_STREAM type decl 
{ streams -trn = type deci trn, 
streams.out_env = type _decl.out_env; 
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type decisopida=.“%; 

type _decl.action code = "stream"; 

type_decl.in_env = streams.in env; 
} 


{streams.trn = ""; 
streams.out_env = {(?:string:"") ); 


} 


type name 
sabe’ (* Cypeadecl] «/)})’ 
{ type name.trn = [ID.%text,"(",type decl.trn, *)\n"); 
type decl.opid = ""; 
type decl.action code = "tname"; } 
|} ID 
{ type name.trn = ID.%text; } 


me 


timers 
: TIMER id list 
{ timers.trn = [id list.trn,"  : PSDL_ TIMER; \n"); 
id_list.in_ env = {(?:string:"") }; 
id list.action code = "timer"; 
id list.tname = ""; 
id Tase.opad.= .""; 
id_list.count = 1; 
id list.exp_env = { (?:ant:"°)); 


{timers.trn = ""; 


) 


ee 


control constraints 
: CONTROL 
{ control constraints.trn = ""; 
control constraints.out_env = { (?:string:"") }; 


) 


| CONTROL OPERATOR ID opt_trig opt_per opt_fin_w constraint options 
more constraints 
{control constraints.trn = 
(control _constraints.in_env (ID. %text ~“"CONSTRUCT")} 
== "composite operator" 
-> ["procedure ",control_constraints.in_env("PARENT"),"_", 
ID.%text," is\n begin\n null;\n end ", 
control constraints.in_env("PARENT"),"_",ID.%text,";\n") 


# ("procedure ",control constraints.in_env ("PARENT"), 
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u "iD, sexi is\n",control_constraints.decl map (ID.%text)iy 
"\nbegin\n", opt trig.streams_ check, 
control constraints.decl_map(ID.%text”"READ"), 
opt trig-pued, 
(control constraints.in_env(ID.%text”“"PROCCALL") == "" 
-> [ID.%text,";\n"] 
# [ID.%text,"(", 
control constraints.in_env(ID.%text“"PROCCALL") ,");\n" 
), 
constraint options.trn,"\n", 
control constraints.uncond output map(ID.%text), 
opt_trig.end_if pred,opt trig.end if streams, 
"end ",control constraints.in envy (PARENT )_ 
" *,ID.ttextpen”) 
) “ more _constraints.trn; 


opt _trig.in_env = control constraints inven, 
constraint _options.in_env = control constraints.in env; 
constraint options.opid = ID.%text; 
control constraints, cur en a= 
{((ID.%text “"PARENT") :control_ constraints.parent) } 
+| opt _trig.out_env 
+| constraint _options.out_env 
+| more constraints.out_env; 


more constraints.parent = control constraints.parent; 
more constraints.in_ env = control _ constraints.in env; 
more constraints.uncond_output_map = 

control constraints.uncond output_map; 
more constraints.decl map = control constraints.decl map; 


} 


{control constraints.trn = "" 


control constraints.out env 


} 


ll =e 


{( (2) strang:"™)3).. 


more constraints 
: OPERATOR ID opt_trig opt_per opt _fin_w constraint options 
more constraints 
{more _constraints[1].trn = 
(more constraints.in env(ID.%text”“"CONSTRUCT") == 
"composite operator" 
-> [procedure ™",more_constraintsi) .inwenv("PARENT™) 7 ao, 
ID.%text," is\n begin\n null;\n end", 
more _constraints[{1].in_env("PARENT")," ",ID.%text,";\n"] 


# ["procedure ",more constraints[1].in_env("PARENT"), 
" "; EDeteGxt is\n",more_constraints[1].decl_ map (ID. %text) | 
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"\nbegin\n",opt_trig.streams_ check, 
more _constraints.decl map (ID.%text”"READ"), 
opt _trig.pred, 
(more _constraints[1]).in_env(ID.%text”“"PROCCALL") == "5" 
-> [ID.%text,";\n"] 
# [ID.%text,"(", 
more constraints[1).in_env(ID.%text~"PROCCALL") ,");\n"] 
), 
constraint options.trn,"\n", 
more _constraints([1).uncond_ output map (ID.%text), 
opt_trig.end_if pred,opt_trig.end if streams, 
"end ",more_constraints[1].in_env("PARENT"), 
~~", 1D. %text, %2\n7) 
) ~ more _constraints[2].trn; 


opt_trig.in_env = more_constraints.in_ env; 
constraint_options.in_env = more_constraints.in_ env; 
constraint _options.opid = ID.%text; 
more _constraints[1).out_env = 
{( (ID. %text” "PARENT") :more_constraints.parent)} +| 
opt_trig.out_env +| 
constraint_options.out_env +| 
more constraints [2] .out_env; 
more constraints[2].in_env = more_constraints[1) .in_env; 
more constraints[2).uncond_output_map = 
more constraints[1).uncond_ output_map; 
more _constraints[2].decl_map = more_constraints[1).decl_map; 


{more constraints.trn = ""; 
more constraints.out_env = ({(?:string:"")} ; 


) 


constraint options 
: OUTPUT id_list IF predicate reqmts_ trace constraint_options 
{ constraint _options[1]).trn = 
{["if ",predicate.trn,"\nthen\n ",id_list.trn,"\nend if;\n", 
constraint options[2].trn]) ; 


constraint _options[2) .opid = constraint _options[1] .opid; 

constraint options[2].in_env = constraint_options[1).in_env; 

constraint _options[1].out_env = id _list.out_env +| 
constraint options [2] .out_env; 

predicate.in env = constraint _options[1].in_env; 

id_list.in_env = constraint_options[1).in_env; 

id list.action_code = "co_ output"; 

id_list.tname — ""; 
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id list.opid = constraint _options.opid; 
id list seount jam, 
id list.exp env = {(?:int:"") }); 


| EXCEPTION ID opt_if predicate reqmts_ trace constraint options 
{ constraint options[1].trn = constraint _options[2] .trn; 
constraint options[1].out_env = constraint _options[2] .out_env; 
constraint options[(2].opid = constraint _options{1].opid; 
constraint _options[2].in_env = constraint _options[1].in_env; 
opt_if predicate.in env = constraint options([1].in_ env; 


| timer_op ID opt _if predicate reqmts trace constraint optiiome 
{ constraint options[1].trn = 
[opt if predicate if timenmooetrm a. , 
constraint options[1] .in_eny (“PAREND™) SPEC. TL", IDsscexte 
");\n",opt if predicate.éend if, constraint options |2).temnr 
constraint _options[1] .out_env = Constraint options (2) cut ea 
constraint options[(2].opid = constraint _options[1] .opid; 
constraint options[2].in_env = constraint options[1] .in_env; 
opt_if predicate in env =~ constrarnyego-perons |!) .ineeny, 


{ constraint loot rons. trn = ", 
constraint _options.out” env = {(?sstring:™™)}; 


OPE unig 
TRIGGERED trigger opt if predicate reqmts trace 
{ opt trig.out_eny = trigger out enw, 
opt _trig.pred = opt _ if predicate.if; 
opt trig.énd if pred-= opt Wf predicace endure, 
opt trig.streams check = trigger 41£, 
opt trig.end if streans = trigger ends, 
trigger.in_ env = opt trig.in env; 
opt_if predicate.in env ™ opt trig.in_ env; 


{opt trig .out_env = {(?7"serange”)"), 
opt _trig.pred = ""; 

opt _trig.end if pred = ""; 

opt _trig.streams check = ""; 

opt _trig.end if streams = ""; 


} 


trigger 
(ALE rd fise 
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(€rigger.if = ("if ",id list .trn, *\nthen\n"]; 
trigger.end if = "end if;\n"; 
trigger.out env = id list.out_env; 

id list.action_code = "by all"; 

id list.tname = ""; 

id list.opid = trigger.in env ("PARENT") ; 
id_list.count = 1; 

ad list .exp env (sq (2cant< "") }; 


| SOME id list 

( trigger tf = ("if “,id list .txrn, *\nthen)\n"}); 
trigger.end if = "end if;\n"; 
trigger.out_env = id list.out_env; 
id list.action_code = "by some"; 
1delast-tname = °"; 
id list.opid = trigger.in_env ("PARENT") ; 
id list.count = 1; 
idmiast.exp eny = { (?:int:"") ); 


{trigger.if = ""; 
trigger.end if = ""; 
trigger.out_env = {(?:string:"") }; 


) a 


opt _per 
:PERIOD time reqmts_ trace 
{ opt_per.trn = "\n"; } 
| 
{ opt_per.trn = ‘ae 


e 
t 


opt fin _w 
: FINISH time reqmts_trace 
{ opt_fin_w.trn = "\n"; } 
| 
(Popeetiniw.trn = ""; ) 


e 
f 


timer op 


> READ 
{ timer op.trn = "PSDL_TIMER.READ"; ) 
| RESET 
{ timer _op.trn = "PSDL_TIMER.RESET"; } 
| START 
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{ timer op-tiaa KESDEnT IMER ao TART Is} 


| STOP | 
{ timer_op.trn = "PSDL_TIMER.STOP"; } 


opt if predicate 
: IF predicate 
{ opt if predicate.if = ["if ",predicate tra, mtenen a), 
opt if predicate.end if = "end if; \n"; 
predicate.in_ env = opt_if_ predicate.in env; 


{opt if predicate.if = ""; 
opt if predicate.end 1f£= =", 


} 


expression list 





>: expression 
{expression list.trn = expression.trn; 
expression list.exp_ env = { (expressgion_list.count :expression.trnijam 


(O°:iZ2s (expression list count) 
(2¢ int 2") 


| expression ',’ expression) list 
{expression list[1].trn = 
[expression.trn,",",expression_list[2].trn]; y 
expression list[1].exp_env = 
{ (expression list[1] .count;:expression gern) ) 7] 
expression list[2].exp_ env; 
expression list[2].count = expression viise(i))-counc + 2, 


expression 
: INTEGER_LITERAL 
{expression.trn = INTEGER LITERAL.%text; } 
| REAL LITERAL 
{expression.trn 
| STRING LITERAL 
{expression.trn 


REAL LITERAL. %text; } 


STRING LITERAL. %text; } 


| TRUE 

{expression.trn = " true "; } 
| FALSE 

{expression.trn = " false "; } 
| ID 


{expression.trn = ID.%text; } 
| type name ‘.” ID “(@expresscionglict. ) 
{expression.trn = [type_name.trn,1ID.%text,"(",expression_list.trn,; 
) le 


expression list .counte=) =) 
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predicate 


relation 


relation 

{predicate.trn = relation.trn; 
predicate.type = relation.type; 
relation.in_ env = predicate.in env; 


} 


relation AND predicate 

{predicate[1).trn = [relation.trn," and ", predicate[{2].trn]; 
predicate([1).type = ""; 

predicate[2].in_env = predicate[1].in_env; 

relation.in_env = predicate[1].in_env; 


} 


relation OR predicate 

{predicate[1].trn = [relation.trn," or ",predicate[2].trn]; 
predicate[1].type = ""; 

predicate[2].in_env = predicate[1].in_env; 

relation.in_ env = predicate[1].in_ env; 


} 


simple expression rel_op simple expression 
{relation.trn = rel_op.trn; 
simple _expression[1].in_env = relation.in env; 
simple expression[2].in_env = relation.in_ env; 
relation.type = 
(simple expression[1].type == "timer" || 
simple expression[2].type == "timer" 
-> "timer" 
# simple expression[1].type == "excp" || 
simple _expression[2].type == "excp" 
-> "excp" 
3 we 
); 
rel op.left_op = simple_expression[1].trn; 
rel op.right_op = simple _expression[2].trn; 
rel op.parent = relation.in_env ("PARENT") ; 
rel_op.opn_type = 
(simple _expression[1].type == "timer" || 
simple _expression[2].type == "timer" 
-> "timer op" 
# "arithmetic" 
); 


265 


| simple expression 


{relation.trn = simple _expression.trn; 
relation.type = simple expression.type; 
simple expression.in_env = relation.in env; 


} 


simple expression 

: INTEGER LITERAL unit 

{simple expression.trn = i2s(s2i (INTEGER_LITERAL. %text) 
* unit.value) ; 

simple expression.type = "timer"; 
} 

| sign INTEGER LITERAL 
{simple _expression.trn = [sign.trn, INTEGER_LITERAL. %text] ; 
simple expression.type = ""; 
} 

| sign REAL LITERAL 
{simple expression.trn = [sign.trn,REAL LITERAL. %text] ; 


simplevexpression.type™= ™; 
} 
| ID 
{simple expression.trn = ID. ttexc; 


simple expression.type = 
(simple expression.in_ env(ID.%text”"CONSTRUCT") == "timer" 
-> 1 t9 
# simple _expression.in_ env (ID.%text ~"CONSTRUCT") 
); 
} 
| STRING LITERAL 
{simple expression.trn = STRING LITERAL. %text; 
simple _expression.type = ""; 
} 
| ’(’ predicate ’)’ 
{simple _expression.trn = ["(",predicate.trn,")"]; 
simple expression.type = predicate.type; 
predicate.in env = simple expression.in env; 


} 


| NOT ID 
{simple expression.trn = ["not ",ID.%text]; 
Simple expression.type = ""; 


} 
| NOT ’ (’ predicate ’)’ 
{simple expression.trn = ["not (",predicate.trn,")"]; 
simple expression.type = ""; 
predicate.in_env = simple _expression.in env; 
} 
| TRUE 
{simple expression.trn = " true "; 
simple expression.type = ""; 


} 
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| FALSE 
{simple expression.trn = " false "; 
simple expression.type = ""; 
} 

| NOT TRUE 
{simple _expression.trn = [" not true "J; 
simple expression.type = ""; 
} 

{| NOT FALSE 
{simple expression.trn = " not false "; 
simple expression.type = ™"; 


} 


od 

{rel op.trn = 
(rel_op.opn_type == "timer _op" 
-> ["PSDL_ TIMER. 
# [rel_op.left_op," < ",rel_op.right_op] 
) + 

} 
| i>! 

{rel op.trn = 
(rel_op.opn_type == "timer_op" 
-> ["PSDL_TIMER. 
# [rel_op.left_op," > ",rel_op.right_op] 
5 


| es! 
{rel op.trn = 
(rel _op.opn_type == "timer _op" 
-> ["PSDL_TIMER. 
# [rel op.left_op," = ",rel_op.right_op] 
3 


| GTE 
{fel op.trn = 
(rel_op.opn_type == "timer op" 
-> ["PSDL_ TIMER. 
# [rel _op.left_op," >= ",rel_op.right_op] 


c 


{| LTE 
{rel _op.trn = 
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= ["PSDL TIMER. 
# {rel _op.left_op," <= ",rel_op.right_op] 
)? 


|} NEQV 
(rel Gpabrn — 
(rel_op.opn_type == "timer op" 
-> ["PSDL_ TIMER. 
# [rel _op.left_op," /= ",rel_op.right_op] | 
); 


(rel _op.opn_type == “timer_op" 


ae! 
{releepavinas 
(rel_op.right_op == "NORMAL" | 
-> [{rel_op.parent," SPEC.DS",rel_ op.left op,".IS NORMAL 
# [rel _op.parent," SPEC.DS",rel op.left op, 

"iS BXCEPTION(™, rel op, er gnt sop.) aa | 





: 
| 
sign 
as | 
{sign.trn = "+ ">; } 
t ee 
{sign.trn = "~ "; } 
: ; 
(Sign. ten =o". } | 
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APPENDIX N PSDL DATA TYPES 


ao Wile: psdl_system.a 
-- Author: Frank Palazzo 
-- Date: 15 Dec 89 


-- Modified: 16 Dec 89 by Laura J. White 


with vstrings, TIMERS; 
package PSDL_ SYSTEM is 


type Int_list is array (1..10) of integer; 


package PSDL STRINGS is new vstrings (50); 
subtype PSDL_ EXCEPTION is PSDL_STRINGS.VSTRING; 
type PSDL TIMER is new TIMERS.TIMER; 


EXCEPTION ERROR, 
BUFFER UNDERFLOW, 
BUFFER OVERFLOW > exception; 


generic 
type ELEMENT TYPE is private; 


package SAMPLED STREAM is 


task DATA_STREAM is 
pragma PRIORITY (10); 
entry CHECK (NEW DATA : out BOOLEAN) ; 
entry GET (VALUE ; out ELEMENT TYPE) ; 
entry GET (VALUE :; out PSDL_ SYSTEM.PSDL_ EXCEPTION) ; 
entry PUT (VALUE : in ELEMENT TYPE); 
entry PUT (VALUE : in STRING); 
entry IS EXCEPTION (NAME : in PSDL_STRINGS.VSTRING; 
CHECK : out BOOLEAN) ; 
entry IS NORMAL (CHECK : out BOOLEAN) ; 


end DATA_STREAM; 
end SAMPLED STREAM; 
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generic 
type ELEMENT TYPE is private; 


package DATAFLOW STREAM is 


task DATA STREAM is 
pragma PRIORITY (10); 
entry CHECK (NEW _DATA : out BOOLEAN) ; 
entry GET (OUTVALUE : out ELEMENT TYPE); 
entry Fur (INVALUE : in ELEMENT TYPE) ; 
end DATA STREAM; 


function FRESH return BOOLEAN; 
end DATAFLOW_ STREAM; 


generic 
type ELEMENT TYPE is private; 
INITIAL VALUE : ELEMENT TYPE; 


package SAMPLED STATE VAR is 


task DATA STREAM is 
pragma PRIORITY (10); 
entry CHECK (NEW DATA : out BOOLEAN) ; 
entry GET (OUTVALUE : out ELEMENT TYPE) ; 
entry PUT (INVALUE : in ELEMENT TYPE) ; 

end DATA_STREAM; 

function FRESH return BOOLEAN; 

end SAMPLED STATE_VAR; 


generic 
type ELEMENT TYPE is private; 
INITIAL VALUE : ELEMENT TYPE; 


package DATAFLOW STATE VAR is 


task DATA STREAM is 
pragma PRIORITY (10); 
entry CHECK (NEW DATA out BOOLEAN) ; 
entry GET (OUTVALUE out ELEMENT TYPE) ; 
entry PUT (INVALUE : in ELEMENT TYPE); 
end DATA_STREAM; 


function FRESH return BOOLEAN; 
end DATAFLOW STATE VAR; 


end PSDL_ SYSTEM; 
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package body PSDL SYSTEM is 
package body SAMPLED STREAM is 


package VSTRING renames PSDL_SYSTEM.PSDL STRINGS; 


type DATA_STREAM MODE is (NORMAL, EXCPTION) ; 
type DATA_STREAM TOKEN (MODE : DATA_STREAM_MODE ;™ NORMAL) is 


record 


INITIALIZED, 
NEW DATA : BOOLEAN : false; 


case MODE is 
when NORMAL => 


N VALUE : ELEMENT TYPE; 
when EXCPTION => 
E VALUE : PSDL SYSTEM.PSDL EXCEPTION; 


end case; 
end record; 


task body DATA_STREAM is 


BUFFER : DATA_STREAM TOKEN; 
TempExcp : PSDL_ SYSTEM.PSDL EXCEPTION; 


begin 
loop 


select 
accept CHECK (NEW DATA : out BOOLEAN) do 


NEW DATA = BUFFER.NEW DATA; 
end CHECK; 


Or 
accept GET (VALUE : out ELEMENT TYPE) do 


1£ not BUFFER.INITIALIZED then 
raise PSDL SYSTEM. BUFFER_UNDERFLOW; 
elsif BUFFER.MODE = EXCPTION then 
raise PSDL SYSTEM.EXCEPTION ERROR; 
else 
VALUE := BUFFER.N VALUE; 
BUFFER.NEW DATA := false; 
end if; 
end GET; 


or 
accept GET (VALUE : out PSDL SYSTEM.PSDL EXCEPTION) do 


i£ not BUFFER.INITIALIZED then 
raise PSDL SYSTEM. BUFFER _UNDERFLOW; 
elsif BUFFER.MODE = NORMAL then 
raise PSDL_SYSTEM.EXCEPTION ERROR; 
else 
VALUE :;:2 BUFFER.E VALUE; 
BUFFER.NEW DATA := false; 
end if; 
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end GET; 
Or 
accept PUT (VALUE : in ELEMENT TYPE) do 
if (BUFFER.MODE = EXCPTION) and BUFFER.NEW DATA then 
raise PSDL_ SYSTEM.EXCEPTION_ERROR; 


else 
BUFFER := (MODE => NORMAL, 
INITIALIZED => true, 
NEW DATA => true, 
N VALUE => VALUE); 
end if; 
end PUT; 


or 
accept PUT (VALUE : in STRING) do 
-- VSTRING.assign (VALUE, TempExcp) ; 


BUFFER := (MODE => EXCPTION, 
INITIALIZED => true, 
NEW DATA => true, 
E VALUE => TempExcp) ; 
end PUT; 


or 
accept IS EXCEPTION (NAME : in PSDL_ STRINGS. VSTRING; 
CHECK : out BOOLEAN) do 
1£ BUFFER.MODE = EXCPTION then 


CHECK := VSTRING.equal (BUFFER.E VALUE , NAME) ; 
else 
CHECK := false; 
end if; 
end IS EXCEPTION; 


or 
accept IS NORMAL (CHECK : out BOOLEAN) do 
CHECK := BUFFER.MODE = NORMAL; 
end IS NORMAL; 
or 
terminate; 
end select; 
end loop; 
end DATA_STREAM; 
end SAMPLED STREAM; 


package body DATAFLOW STREAM is 


type DATA STREAM TOKEN is 


record 
INITIALIZED, 
NEW DATA : BOOLEAN := false; 
VALUE : ELEMENT TYPE; 


end record; 


272 








task body DATA_STREAM is 


BUFFER : DATA STREAM TOKEN; 


begin 
loop 
select 
accept CHECK (NEW _DATA : out BOOLEAN) do 
NEW DATA := BUFFER.NEW_ DATA; 
end CHECK; 
or 
accept GET (OUTVALUE : out ELEMENT TYPE) do 
if not (BUFFER.INITIALIZED and BUFFER.NEW DATA) then 
raise PSDL_ SYSTEM. BUFFER _UNDERFLOW; 
else 
OUTVALUE := BUFFER.VALUE; 
BUFFER.NEW DATA := false; 
end if; 
end GET; 
OF 
accept PUT (INVALUE : in ELEMENT TYPE) do 
if BUFFER.NEW DATA then 
raise PSDL_ SYSTEM.BUFFER_ OVERFLOW; 
else 
BUFFER.VALUE := INVALUE; 
BUFFER.NEW DATA := true; 
BUFFER.INITIALIZED :;:= true; 
end if; 
end PUT; 
or 
terminate; 
end select; 
end loop; 


end DATA_STREAM; 


function FRESH return BOOLEAN is 
RESULT : BOOLEAN; 

begin 
DATA_STREAM. CHECK (RESULT) ; 
return (RESULT) ; 

end FRESH; 


end DATAFLOW STREAM; 
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package body SAMPLED STATE VAR is 
type DATA STREAM TOKEN is 


record 
INITIALIZED, 
NEW_DATA : BOOLEAN := false; 
VALUE : ELEMENT TYPE = INITIAL VALUE; 


end record; 
task body DATA_STREAM is 


BUFFER : DATA_STREAM TOKEN; 


begin 
loop 
select 
accept CHECK (NEW DATA : out BOOLEAN) do 
NEW DATA := BUFFER.NEW_ DATA; 
end CHECK; 
or 


accept GET (OUTVALUB : out BLEMENT TYPE) do 
if not BUFFER.INITIALIZED then 
raise PSDL SYSTEM.BUFFER_UNDERFLOW; 


else 
OUTVALUE := BUFFER.VALUE; 
BUFFER.NEW DATA := false; 
end if; 
end GET; 
or 
accept PUT (INVALUE : in ELEMENT TYPE) do 
BUFFER. VALUE >= INVALUE; 
BUFFER. INITIALIZED ;:= true; 
BUFFER.NEW DATA >= true; 
end PUT; 
Or 
terminate; 
end select; 
end loop; 


end DATA STREAM; 


function FRESH return BOOLEAN is 
RESULT : BOOLEAN; 

begin 
DATA_STREAM. CHECK (RESULT) ; 
return RESULT; 

end FRESH; 


end SAMPLED STATE VAR; 
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package body DATAFLOW STATE VAR is 


type DATA STREAM TOKEN is 


record 
INITIALIZED, 
NEW DATA : BOOLEAN := false; 
VALUE : ELEMENT TYPE := INITIAL VALUE; 


end record; 
task body DATA_STREAM is 


BUFFER : DATA_STREAM TOKEN; 
begin 
loop 
select 
accept CHECK (NEW DATA : out BOOLEAN) do 
NEW DATA := BUFFER.NEW DATA; 
end CHECK; 


or 
accept GET (OUTVALUE : out ELEMENT TYPE) do 
if not (BUFFER.INITIALIZED and BUFFER.NEW DATA) then 
raise PSDL_ SYSTEM. BUFFER_UNDERF LOW; 
else 
OUTVALUE := BUFFER. VALUE; 
BUFFER.NEW DATA := false; 
end if; 
end GET; 


or 
accept PUT (INVALUE : in ELEMENT TYPE) do 
if BUFFER.NEW_ DATA then 
raise PSDL_ SYSTEM. BUFFER _ OVERFLOW; 
else 
BUFFER.VALUE := INVALUE; 
BUFFER.NEW DATA := true; 
BUFFER.INITIALIZED := true; 
end if; 
end PUT; 


or 
terminate; 
end select; 
end loop; 
end DATA STREAM; 
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function FRESH return BOOLEAN is 
RESULT : BOOLEAN; 

begin 
DATA STREAM. CHECK (RESULT) ; 
return (RESULT) ; 

end FRESH; 


end DATAFLOW_STATE VAR; 


end PSDL SYSTEM; 


276 





file: 
author: 
date: 
modified: 


APPENDIX O KODIYAK SPECIFICATIONS FOR STATIC SCHEDULER 


pre_ss.k 

laura marlowe 

dec 88 

dec 89 by laura j. white 


'definitions of lexical classes 


%define 
%define 
%define 
%define 
%define 
%define 
%define 


Digit 
Int 
Letter 
Alpha 
Blank 
Char 
Quote 


! definitions of 


! definitions of 


GTE 
LTE 

NEQV 

ARROW 

TYPE 

OPERATOR 
SPECIFICATION 
END 

GENERIC 

INPUT 

OUTPUT 

STATES 
INITIALLY 
EXCEPTIONS 
MAX _EXEC_TIME 
MAX _RESP_TIME 
MIN CALL PERIOD 
MICROSEC 


: [0-9] 

: {Digit }+ 

> [a-zA-Z_]} 

> ({Letter)} | {Digit }) 
:{ \n]j 

si {)) 

re Baa 


white space 


:{Blank}+ 


compound symbols and keywords 


2AM 

oN ca 8 

2 fant 

.S =e 

:type | TYPE 

:operator | OPERATOR 

:specification|SPECIFICATION 

:end| END 

:generic|GENERIC 

:input | INPUT 

:output | OUTPUT 

:states|STATES 

sinitially] INITIALLY 

:exceptions | EXCEPTIONS 

smaximum[ Jexecution[ ]Jtime|MAXIMUM[ ]EXECUTION[ ] TIME 
smaximum[ ])response[ ])time|MAXIMUM[{ ]RESPONSE[ ] TIME 
sminimum[{ ])calling[ ]period|MINIMUM[ ]CALLING[ ] PERIOD 
smicrosec |MICROSEC|us 
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MS 

SEC 

MIN 

HOURS 

BY 

KEYWORDS 
DESCRIPTION 
AXIOMS 
IMPLEMENTATION 
ADA 

GRAPH 

DATA STREAM 
TIMER 
CONTROL 
TRIGGERED 
ALL 

SOME 

PERIOD 
FINISH 
EXCEPTION 
READ 

RESET 

START 

STOP 

IF 

NOT 

AND 

OR 

TRUE 

FALSE 

ID 

STRING LITERAL 


INTEGER _ LITERAL 


REAL LITERAL 
TEXT 


:ms |MS 

:sec|SEC 

:min|MIN 

>hours|HOURS|hrs|HRS|hr|HR 

:by[{ ]requirements|BY[ ]REQUIREMENTS 
> keywords | KEYWORDS 

:description| DESCRIPTION 
>axioms | AXIOMS 

:implementation| IMPLEMENTATION 
>;ada|Ada]ADA 

: graph |GRAPH 

:data[ ]stream|DATA[ ]STREAM 
:timer|TIMER 

:control[ ]constraints|CONTROL[ ]CONSTRAINTS 
:triggered/| TRIGGERED 

:sby{ Jall|{BY[ JALL 

:by{ ]some|BY[ ]SOME 

:period|PERIOD 

:finish[ ]within|FINISH[ ]WITHIN 
:exception| EXCEPTION 


ee 


read[{ ]Jtimer|READ[ ]TIMER 


:reset[ Jtimer|RESET[ ]TIMER 
:start[ ]timer|START[ ] TIMER 
:stop[ ]timer|STOP[ ]TIMER 
:if|IF 

NEw EMnoOr NOL 

Ly | “and"| "AND" 

S77") "or"| "OR" 

>true| TRUE 


false|FALSE 


: {Letter} {Alpha} * 

: {Quote} {Char} * {Quote} 
: {Int } 

*{Int } ©." {ine 

nr Paiic hat as 


! operator precedences 
! left means group and evaluate from the left 


$left OR; 
$left AND; 
$left NOT; 


eleft 0 ¢<' 4 >? 


$left oe 


%% 


‘=!, GTE, LTE, NEQV; 


278 








! attribute declarations for nonterminal symbols 


Beart { ten: string; }; 

psdl { trn: string; }; 

component { trn: string; }; 
data _ type { trn: string; }; 
operator { trn: string; }; 

type spec { trn: string; }; 
Ppyeencagec!] 1 list { trn: string; }; 
type decl ( trn: string; }; 
Spespec 0 list ({ trn: string; }; 
operator spec { trn: string; }; 
interface { trn: string; }; 
attribute { trn: string; }; 

time { trn: string; }; 

unit { value: int; }; 

edetaeat { trn: string; }; 

reqmts trace { trn: string; }; 
functionality { trn: string; }; 
keywords ({ trn: string; }; 

informal desc { trn: string; }; 
formal desc { trn: string; }; 

type _impl { trn: string; }; 

op_impl 0 list { trn: string; }; 
operator impl { trn: string; children: string; }; 
psdl_impl { trn: string; children: string; }; 
data_ flow diagram { trn: string; }; 
ink QO list { trn: string; }; 

link { trn: string; }; 

opt_time ({ trn: string; }; 

streams { trn: string; }; 

type_name { trn: string; }; 

timers { trn: string; }; 

control constraints ( trn: string; children: string; }; 
constraint options { trn: string; children: string; }; 
Sptytrig { trn: string; }; 

trigger { trn: string; }; 

opt_per { trn: string; }; 

opt_fin w { trn: string; }; 
timer op { trn: string; }; 

opt_if predicate ( trn: string; }; 
predicate { trn: string; }; 
expression list { trn: string; }; 
expression { trn: string; }; 
relation (trn: string; }; 

simple expression { trn: string; }; 
exception_expr (trn: string; }; 

rel op {trn: string; }; 

sign {trn: string; }; 
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lattribute declarations for terminal symbols 


ID{ %text; string; aie 

TEXT{ %text: string; }; 

STRING LITERAL { %text: string; }; 
INTEGER LITERAL{ %text: String; 7 
REAL LITERAL{ %text: string; }; 


%% 


'psdl grammar 


start 
: psdl 
{ toutput (psdl.trn); } 


e 
tf 


psdl 
: psdl component 
{ psdi[(1}.trn = [psd1[2].trn,component.trn]; } 
| 
{ psdl[(1).trn = ""; } 
| 
component 
; data_type 
{ component.trn = data _type.trn; } | 
| operator 
{ component .trn = operator.trn; } : 
; | 
| 
data type | 
TYPE ID type_spec type _impl 
{ data_type.trn = [type spec.trn,type impl.trn];  } 
operator 
OPERATOR ID operator spec operator imp] 
{ operator.trn = ["LINEAGE", "\n",ID.%text,"\n", 
operator _impl.children, "END LINEAGE", "\n", 
ID. %text,"\n",operator spec.trn, 
operator impl.trn]; } 
type spec 
SPECIFICATION type decl_ 1 list op_spec_0 list functionality END 
{ type spec.trn = op spec Oris eon a 
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type decl 1 list 
; type decl 
{ type_decl_1 list.trn = type decl.trn; } 
| 
{type _decl 1 list.trn = ""; } 


type _decl 
; id_list ’:’ type name 
{ type _decl.trn = id list.trn; } 
| id_list ’:’ type name ’,’ type decl 
{ type_decl.trn = [id_list.trn,type decl.trn]; } 


op_spec 0 list 
: Op_spec_0 list OPERATOR ID operator spec 
{ op_spec_0 list[1].trn = [op_spec_0_list[2].trn,ID.%text,"\n", 
operator spec.trn]; } 
| 


{ op_spec 0 list.trn = ""; } 


=e 


operator spec 
: SPECIFICATION interface functionality END 
{ Operator spec.trn = interface.trn; } 


=e 


interface 
; interface attribute reqmts trace 
{ interface{1].trn = [interface[2].trn,attribute.trn]; } 


{interface.trn = ""; } 


=e 


attribute 
; GENERIC type decl 
{ attribute.trn = ""; } 
| INPUT type decl 
{ attribute.trn = ""; } 
| OUTPUT type decl 
{ attribute.trn = ""; } 
| STATES type _decl INITIALLY expression_list 
{ attribute.trn = ("STATE", "\n",type decl.trn, "ENDSTATE", "\n"]; } 
| EXCEPTIONS id list 
{ attribute.trn = "™"; } 
| MAX _EXEC_TIME time 
{ attribute.trn = ["MET","\n",time.trn,"\n"J; } 
| MIN CALL PERIOD time 
{ attribute.trn = ["MCP","\n",time.trn,"\n"J]; } 
| MAX_RESP_TIME time 
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{ attribute.trn = (“MRE em! cime-eaun, Vn) 


e 
f 


Taga st 
ID %,’ 1d Tvst 
{ id list[{1].trn 
| ID 
{- 2d liste ern 


[ID.%text,"\n",id list [2Zjetrn jas 


[ID.%text, "\n"]; } 


time 
INTEGER LITERAL unit ; 
{ time.trn = i2s(s2i (INTEGER LITBRAL.%text) *unit.value); } ) 
| 
unit 
MICROSEC 
{ unit.value = 1; } 
| MS 
{ unit.value = 1000; } 
| SEC 
{ unit.value = 1000000; } 
| MIN 
{ unit.value = 60000000; } 
| HOURS 


{ unit.value = 3600000000; } 


{ unit.value = 1000; } 


reqmts trace 
BY sidulist 


{ reqmts trace.trn = ™"; } 
| 
(Sreqmts trace Grn. Fuga) 
functionality 
keywords informal desc formal desc | 
{ functionality.trn = ""; } 
; 
keywords 


KEYWORDS id list 
{ keywords.trn = "\n"; } 


{ keywords.trn = ""; } . 


| 
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informal desc 
: DESCRIPTION TEXT 
{ anformal desc.trn = "\n"; } 


jancormalidesc.trn =a"; } 


“e 


formal desc 
: AXIOMS TEXT 
{ formal _desc.trn = "\n"; } 


{ formal desc.trn = ""; } 


type _impl 
: IMPLEMENTATION ADA ID END 
{ type_impl.trn = [ID.%text,"\n"]; } 
| IMPLEMENTATION type_name op_impl 0 list END 
{ type_impl.trn = op_impl 0 list.trn; )} 


op_impl_ 0 list 
; op_impl_0_list OPERATOR ID operator _impl 
{ op_impl_ 0 list[1].trn = [op_impl 0 list[2].trn,ID.%text,"\n", 
operator _impl.trn]; } 


(yep imp! 0 list (1) .trneo"™; } 


operator impl 
IMPLEMENTATION ADA ID END 
{ operator _impl.trn = [ID.%text,"\n"]; 
operator impl.children = ["ATOMIC","\n"]; } 
| IMPLEMENTATION psdl_impl 
{ operator _impl.trn = psdl_impl.trn; 
operator _impl.children = psdl_impl.children; } 


psdl_impl 
: data flow diagram streams timers control constraints informal_desc END 
{ psdl_impl.trn = [data_flow_diagram.trn,control_constraints.trn); 
psdl_impl.children = control_constraints.children; } 


data_flow diagram 


: GRAPH link_0 list 
{ data flow diagram.trn = link_0 list.trn; } 
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link 0 list 
link 0 list link ( 
{ link_0 list[(1i].trn = [link_0 list (2)¢trn, linker 


{ link 02! 2sc-ern =e 


link 
ID ’.’ ID Opt atime ARROW erp 
{ link.trn = ["LINK","\n", ID(1].%text, "\n", ID{2].stext, = 
opt time.trn,"\n"7 9b). teene, i 
opt_time 
‘=! ceame 
{ Opt time 7trn = je ime crn) 
| 
{ Cpe time jer —sa0 la) 
streams 
DATA_STREAM type_decl 
{ streams.trn = ""; } 
| 
{streams.trn = ""; } 


type_name 
Teast ype dec laa 





Peeyrecuname; CL ne =) 
| ID 
{ type _name.trn = "" ; } 
timers 

TIMER id list : 
) 5 ' 

jetimers.trn =) 7) 

{timers.trn = WW. ) 


f 


control constraints 
: CONTROL 
{ control constraints.trn = ""; | 
control constraints.children =*"; } 
| CONTROL OPERATOR ID opt_trig opt_per opt_fin_w constraint _options 
{control constraints.trn = [ID.%text,"\n"“,opt_per.trn,opt_fin w.trn, 
constraint _options.trn]; 
control constraints.children = [ID.%text, "\n", 
constraint _options.children]; } 
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{control constraints.trn = ""; 
control constraints.children = "";} 


constraint options 
: OUTPUT id list IF predicate reqmts trace constraint options 
{ constraint options([1].trn = constraint options([2].trn; 
constraint _options.children = constraint options [2].children; } 
| EXCEPTION ID opt_if predicate reqmts trace constraint_options 
{ constraint options[1].trn = constraint_options[2].trn; 
constraint options.children = constraint_options[2] .children; } 
| timer_op ID opt_if predicate reqmts_trace constraint_options 
{ constraint options[1].trn = constraint _options[2].trn; 
constraint options.children = constraint_options[2].children; } 
| OPERATOR ID opt trig opt_per opt_fin_w constraint_options 
{ constraint _options{1].trn = [ID.%text,"\n",opt_per.trn, 
opt_fin_w.trn, constraint _options[2].trn]; 
constraint options.children = [ID.%text, "\n", 
constraint _options(2].children];)} 


{ constraint_options.trn = ""; 
constraint options.children = "";} 


=e 


opt_trig 
: TRIGGERED trigger opt_if predicate regmts_ trace 
{ optiiteig.trn= "*;.) 


{opt trig.trn = ""; } 


=e 


trigger 
: ALL id list 
{ trigger.trn = ""; } 
} SOME id list 
{"trrqgersern = ""; } 


{trigger.trn = ""; } 


™=e 


opt_per 
:PERIOD time reqmts trace 
{ Opt per.trn = ("PERIOD", "\n",time.trn,"\n"]; } 
| 
{ opt _per.trn = ""; } 
, 
opt_fin_w 


: FINISH time reqmts trace 
{ opt fin_w.trn = ("WITHIN","\n",time.trn,"\n"]; ) 
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{ opt fin w.tru = WH. Y | 


timer op 


“e 


: READ 
{ timer op.trn = ""; } 
| RESET 
{ timer op.trn = ""; } ; 
| START 
( timer opstrn 2s) 

| STOP 
{ timer op trn_= "7 


opt_if predicate 
: IF predicate 
{ opt if predicate.trne~, | 
| 
{opt if predicate.trn = ""; } 


expression list 


>: expression 
(expression J13b. trun =e 
| €xpressiton, 97 expression ise 
(Expressienelist (ll) stro a 
; 
expression 


: INTEGER LITERAL 
{expression.trn = ""; } 
| REAL LITERAL 


{expression.trn = ""; } 
| STRING LITERAL 

{expression.trn = ""; } 
| TRUE 

{expression.trn = ""; } 
| FALSE 

{expression.trn = ""; } 
| ID 

{expression.trn = ""; } 


| type mame ".7 ID’ {(" (expréessiong! iste a 
{expreéssion.trn = ""; } 
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predicate 
2erelation 
{predicate.trn = ""; } 
| relation AND predicate 
{predicate[(1].trn = ""; } 
| relation OR predicate 
{predicate[1l]}.trn = ""; } 


=e 


relation 
; Simple expression rel _op simple expression 
{relation.trn = ""; } 
| simple _expression 
{relation.trn = "™"; } 


=e 


simple expression 

; Sign INTEGER_LITERAL unit 

{simple expression.trn = ""; } 
| sign REAL_LITERAL 

{simple _expression.trn = ""; } 
| ID 

{simple _expression.trn = ""; } 
| STRING LITERAL 

{simple expression.trn = ""; } 
| ’(’ predicate ’)’ 

{simple expression.trn = ""; } 
| NOT ID 

{simple expression.trn = "";} 
| NOT ’(’ predicate ’)’ 

{simple expression.trn = ""; } 
| TRUE 

{simple expression.trn = ""; } 
| FALSE 

{simple _expression.trn = ""; } 
| NOT TRUE 

{simple _expression.trn = ""; } 
| NOT FALSE 

{simple expression.trn = ""; } 


=e 


rel op 
° ee 

{rel_op.trn = ""; } 
| my! 

{rel_op.trn = ""; } 
| ’=/ 

{rel_op.trn = ""; } 
| GTE 

{rel_op.trn = ""; ) 
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| LTE 
{rel op.trn = ""; } 
| NEOV 


{rel Vop- tin AS ae 
fea 


ll 


(rel op erm 2s.) en 


sign 
raf 
{sign.trn = ""; } 
| te A 
{sign.trn = ""; } 


{sign.trn = "™"; } 
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APPENDIX P STATIC SCHEDULER DRIVER 


-- file: driver.a 
-- author: murat kilic 
-- date: nov 89 


-- modified: 26 dec 89 by laura j. white 


with TEXT _I0O; 

with FILES; use FILES; 

with FILE PROCESSOR; 

with EXCEPTION HANDLER; 

with TOPOLOGICAL SORTER; 
with HARMONIC BLOCK BUILDER; 
with OPERATOR SCHEDULER; 


procedure STATIC SCHEDULER is 


THE GRAPH 
PRECEDENCE LIST 
SCH_INPUTS 
AGENDA 

BASE BLOCK 

H_B_ LENGTH 
STOP_TIME 


DIGRAPH.GRAPH; 
DIGRAPH.V_LISTS.LIST; 
SCHEDULE INPUTS _LIST.LIST; 
SCHEDULE INPUTS LIST.LIST; 
INTEGER; 

INTEGER; 

INTEGER := 0; 


begin 
FILE PROCESSOR.SEPARATE DATA (THE GRAPH) ; 
FILE PROCESSOR.VALIDATE_DATA (THE GRAPH) ; 
TOPOLOGICAL SORTER.TOPOLOGICAL SORT (THE GRAPH, PRECEDENCE LIST); 
HARMONIC _BLOCK_BUILDER.CALC_PERIODIC_EQUIVALENTS (PRECEDENCE LIST) ; 
HARMONIC BLOCK BUILDER.FIND BASE BLOCK (PRECEDENCE LIST, BASE BLOCK) ; 
HARMONIC _BLOCK_BUILDER.FIND_BLOCK_LENGTH (PRECEDENCE_LIST,H_B_ LENGTH) ; 
OPERATOR _SCHEDULER.TEST DATA(PRECEDENCE LIST, H_B LENGTH) ; 
loop 
doE NOT (TEST VERIFIED) then 
TEXT IO.PUT("Although a schedule may be possible, there is no "); 
TEXT IO.PUT_ LINE ("guarantee that it will execute"); 
TEXT _IO.PUT LINE("within the required timing constraints."); 
TEXT _IO.NEW_LINE; 
end if; 
begin 
OPERATOR _SCHEDULER.SCHEDULE_INITIAL_SET 
(PRECEDENCE LIST,SCH_INPUTS,H_B LENGTH, STOP_TIME) ; 
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OPERATOR SCHEDULER.SCHEDULE_REST_OF_ BLOCK 
(PRECEDENCE LIST,SCH_INPUTS,H_B_ LENGTH, STOP_TIME) ; 
OPERATOR_SCHEDULER.CREATE STATIC SCHEDULE 
(THE GRAPH,SCH INPUTS,H B LENGTH) ; 
TEXT ILO. PUI(°A feasibierschedules tcuna, =. a, 
TEXT IO.PUT_LINE("the Harmonic Block with Precedence "); 
TEXT IO.PUT_LINE(" Constraints Scheduling Algorithm Used. "); 


SCH_INPUTS := null; 
exit; 
exception 
when OPERATOR SCHEDULER.MISSED DEADLINE => 
null; 
when OPERATOR _SCHEDULER.OVER_ TIME => 
null; 
end; 
begin 


HARMONIC BLOCK BUILDER.CALC PERIODIC EQUIVALENTS 
(THE GRAPH. VERTICES) ; 

OPERATOR_SCHEDULER.SCHEDULE WITH EARLIEST START 

(THE GRAPH,AGENDA,H B_ LENGTH) ; 
OPERATOR SCHEDULER.CREATE_STATIC_SCHEDULE 

(THE GRAPH, AGENDA, H B_ LENGTH) ; 
TEXT IO.PUT_LINE("A feasible schedule found, the Earliest Start"); 
TEXT_IO.PUT_LINE("Scheduling Algorithm Used. "); 
AGENDA := null; 


exit; 
exception 
when OPERATOR_SCHEDULER.MISSED DEADLINE => 
null; 
when OPERATOR _SCHEDULER.OVER_ TIME => 
null; 
end; 
begin 


OPERATOR _ SCHEDULER.SCHEDULE WITH EARLIEST DEADLINE 
(THE GRAPH, AGENDA, H B LENGTH) ; 
OPERATOR SCHEDULER.CREATE STATIC SCHEDULE 
(THE GRAPH, AGENDA, H B LENGTH) ; 
TEXT _IO.PUT_LINE("A feasible schedule found, the Earliest "); 
TEXT IO.PUT LINE("Deadline Scheduling Algorithm Used. "); 


AGENDA := null; 
exit; 
exception 
when OPERATOR_SCHEDULER.MISSED DEADLINE => 
null; 
when OPERATOR SCHEDULER.OVER_TIME => 
null; 
when OPERATOR _SCHEDULER.MISSED OPERATOR => 
null; 
end; 
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end loop; 


exception 


when FILE PROCESSOR.CRIT OP _LACKS MET => 
EXCEPTION HANDLER.CRIT O L MET (Exception Operator) ; 


when FILE PROCESSOR.MET NOT _LESS THAN PERIOD => 
EXCEPTION HANDLER.MET N_ L T PERIOD (Exception Operator) ; 


when FILE_PROCESSOR.MET NOT _LESS THAN MRT => 
EXCEPTION _HANDLER.MET N_L T MRT (Exception Operator) ; 


when FILE PROCESSOR.MCP_ NOT LESS THAN MRT => 
EXCEPTION HANDLER.MCP_N_ L T MRT (Exception Operator) ; 


when FILE _PROCESSOR.MCP_LESS_ THAN MET => 
EXCEPTION HANDLER.MCP L T MET(Exception Operator) ; 


when FILE PROCESSOR.MET IS GREATER THAN FINISH WITHIN => 
EXCEPTION HANDLER.MET I_G T FINISH WITHIN (Exception Operator) ; 


when FILE PROCESSOR.SPORADIC OP LACKS MCP => 
EXCEPTION HANDLER.SPORADIC O L MCP (Exception Operator) ; 


when FILE PROCESSOR.SPORADIC OP_LACKS MRT => 
EXCEPTION HANDLER.SPORADIC O _L MRT(Exception Operator) ; 


when SCHEDULE INPUTS LIST.BAD VALUE => 
EXCEPTION HANDLER.S I _L BAD VALUE; 


when DIGRAPH.V_LISTS.BAD VALUE => 
EXCEPTION HANDLER.V_L BAD VALUE; 


when DIGRAPH.E LISTS.BAD VALUE => 
EXCEPTION HANDLER.E_L BAD VALUE; 


when HARMONIC BLOCK BUILDER.NO BASE BLOCK => 
EXCEPTION HANDLER.NO_B_ BLOCK; 


when HARMONIC BLOCK BUILDER.NO_OPERATOR_IN LIST => 
EXCEPTION HANDLER.NO OP_IN LIST; 


when HARMONIC BLOCK BUILDER.MET NOT LESS THAN PERIOD => 
EXCEPTION HANDLER.MET N_L T_ PERIOD (Exception Operator) ; 


end STATIC SCHEDULER; 
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APPENDIX Q STATIC SCHEDULER ERROR HANDLER 


— <= =e ame Ge ee cm cm am cee cee re ee ee ee ee ee es ec cs cos ces ces ce ce ce es es es es es ces ee ee ees es ees ees ees es es ees ee ee es es es es ees es es ees ee ee ee ee 


-- file: e handler s.a 
-- author: murat kilic 
-- date: nov 89 


-- modified: dec 89 murat kilic 


— oe qe cue ee cee ee es ee ee ee ee ee ee ee ee es es es ee es ee ee es ee es es es es es es ee ee es es es es es es es es es es es es es ee ee ee ee eee eee ee ee eee ee ee ee ee ee ee 


with FILES; use FILES; 

package EXCEPTION HANDLER is 
procedure CRIT O L MET(Exception_ Operator : in OPERATOR_ID); 
procedure MET _N L T PERIOD(Exception Operator : in OPERATOR_ID); 
procedure MET N L T MRT(Exception_ Operator : in OPERATOR_ID); 
procedure MCP _N L T MRT(Exception_ Operator : in OPERATOR_ID); 
procedure MCP _L T MET(Exception Operator :; in OPERATOR ID); 
procedure MET I G T FINISH_WITHIN (Exception Operator : am OPERATOR_ID) ; 
procedure PERIOD L T FINISH _WITHIN (Exception Operator : in OPERATOR_ID); 
procedure SPORADIC O L MCP (Exception Operator : in OPERATOR_ID); 
procedure SPORADIC_O L MRT (Exception_Operator : in OPERATOR_ID); 
procedure S_I_L BAD VALUE; 
procedure V_L BAD VALUE; 
procedure E L BAD VALUE; 
procedure NO_B BLOCK; 
procedure NO OP_IN LIST; 


end EXCEPTION HANDLER; 
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APPENDIX R STATIC SCHEDULER ERROR HANDLER 


-- file: e handler b.a 
-- author: murat kilic 
-- date: nov 89 


-- modified: dec 89 by murat kilic 


with TEXT IO; 
with FILES; use FILES; 


package body EXCEPTION _HANDLER is 


procedure CRIT O L MET(Exception_Operator : in OPERATOR_ID) is 
begin 

TEXT_IO.PUT ("Critical Operator "); 

VARSTRING.PUT (Exception Operator) ; 

TEXT IO.PUT_LINE (" must have an MET") ; 
end CRIT O L MET; 


procedure MET N L T PERIOD(Exception Operator : in OPERATOR_ID) is 


begin 
TEXT IO.PUT ("MET is greater than PERIOD in operator "); 
VARSTRING.PUT_LINE (Exception_Operator) ; 

end MET N L T PERIOD; 


procedure MET N L T MRT(Exception_ Operator : in OPERATOR_ID) is 
begin 
TEXT IO.PUT ("MET is greater than MRT in operator "); 
VARSTRING.PUT_ LINE (Exception_Operator) ; 
end MET N_L T MRT; 


procedure MCP_N L T MRT (Exception Operator ; in OPERATOR_ID) is 
begin 
TEXT IO.PUT ("MCP is greater than MRT in operator "); 
VARSTRING. PUT_LINE (Exception Operator) ; 
end MCP_N _L T MRT; 


procedure MCP_L T MET (Exception _Operator : in OPERATOR_ID) is 
begin 
TEXT IO.PUT ("MCP is less than MET in operator "); 
VARSTRING.PUT_ LINE (Except ion Operator) ; 
end MCP _L T MET; 
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procedure MET I G T FINISH WITHIN | 
(Exception Operator : in OPERATOR ID) is | 

begin 

TEXT _IO.PUT ("MET is greater than FINISH WITHIN in operator "); 

VARSTRING.PUT LINE (Exception Operator) ; 


end MET I G T FINISH_WITHIN; 


procedure PERIOD L T FINISH WITHIN 
(Exception Operator : in OPERATOR _ID) is 
begin 
TEXT IO.PUT ("Period is less than FINISH WITHIN in operator "); 
VARSTRING.PUT LINE (Exception Operator) ; 
end PERIOD L T FINISH WITHIN; 


procedure SPORADIC _O L MCP (Exception Operator : in OPERATOR_ID) is 
begin 

TEXT IO.PUT ("Sporadic Operator "); 

VARSTRING.PUT (Exception Operator); 

TEXT IO.PUT LINE (" must have an MCP"); 
end SPORADIC _O_L MCP; 


procedure SPORADIC _O_L MRT (Exception _Operator : in OPERATOR_ID) is 
begin 
TEXT IO.PUT ("Sporadic Operator "); 
VARSTRING.PUT (Exception Operator) ; 
TEXT IO.PUT_LINE (" must have an MRT"); 
end SPORADIC O_L MRT; ( 
| 
: 


procedure S_I_L BAD VALUE is 

begin 
TEXT IO.PUT ("You try to get a schedule input where your pointer "); 
TEXT_IO.PUT LINE ("1s pointing a nulli@ectcra) 

end S I L BAD VALUE; 


procedure V_L BAD VALUE is 
begin 
TEXT IO.PUT ("You try to get an operator where your pointer "); | 
TEXT IO.PUT LINE ("is pointing @ null recoras:),; | 
end V_L_ BAD VALUE; | 


procedure E _L BAD VALUE is P 

begin 
TEXT IO.PUT ("You try to get a link data where your pointer "); | 
TEXT_IO.PUT_LINE ("is pointing a null record."); 

end E_L BAD VALUE; 


procedure NO B BLOCK is 
begin 

TEXT IO.PUT LINE ("There is no BASE BLOCK in this system."); 
end NO B BLOCK; 
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procedure NO OP_IN LIST is 
begin 
TEXT I0O.PUT_LINE ("There is no CRITICAL OPERATOR in this system."); 
end NO OP_IN_ LIST; 


end EXCEPTION _HANDLER; 
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APPENDIX S STATIC SCHEDULER GLOBALS 


— <<) oe ee > ee ee ee eee ee ee i we ee em om 6 6 2 ee ee ee | 2 ee © 3 2 2 2 2 © © 28 ee oe oe ow om om 2 oe © © © © ew oe oe ao == 


-- file: files.a 

-- author: murat kilic 

-- date: oct 89 

—= ModLeuca. dec 89 by laura j. white 


—- ee ee ee ee ee ee ee ee ee ee ee ee ses es es es es es es es es es es es es es es es es se ee ee ee ee ee es ee ee es es ee eet ee ee ee ee ee oe oe oe oe 


with VSTRINGS; 
with SEQUENCES; 
with GRAPHS; 


package FILES is 


package VARSTRING is new VSTRINGS (80) ; 
use VARSTRING; 


subtype OPERATOR _ID is VSTRING; 
subtype VALUE is NATURAL; 


subtype 
subtype 
subtype 
subtype 
subtype 
subtype 
subtype 
subtype 
subtype 


MET is VALUE; 
MRT is VALUE; 
MCP is VALUE; 
PERIOD is VALUE; 
WITHIN is VALUE; 
STARTS is VALUE; 
STOPS is VALUE; 
LOWERS is VALUE; 
UPPERS is VALUE; 


Exception Operator : OPERATOR_ID; 


TEST VERIFIED : BOOLEAN := TRUE; 


type OPERATOR is 


record 
THE OPERATOR ID : OPERATOR _ID; 
THE MET : MET r= 0; 
THE MRT ; MRT SS Ue 
THE MEE : MCP := 0; 
THE PERIOD : PERIOD := QO; 
THE WITHIN > WITHIN =O? 


end record; 


package 


DIGRAPH is new GRAPHS (OPERATOR) ; 
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type SCHEDULE_INPUTS is 
record 
THE OPERATOR : OPERATOR_ID; 
THE START : STARTS :;:= 0; 
THE STOP : STOPS s= 0; 
THE LOWER : LOWERS := 0; 
THE UPPER : UPPERS := Q; 


end record; 
package SCHEDULE_INPUTS LIST is new SEQUENCES (SCHEDULE_INPUTS) ; 


type OP_INFO is 


record 
NODE : OPERATOR; 
SUCCESSORS : DIGRAPH.V_ LISTS.LIST; 
PREDICESSORS : DIGRAPH.V_LISTS.LIST; 


end record; 
package OP_INFO_ LIST is new SEQUENCES (OP_INFO); 


end FILES; 
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APPENDIX T STATIC SCHEDULER FILE PROCESSOR | 


-- file: fp s.a 

-= authors: laura marlowe 
-- murat kilic 
-- date: nov 89 


with FILES; use FILES; 
package FILE PROCESSOR is 


procedure SEPARATE DATA (THE GRAPH : in out DIGRAPH.GRAPH) ; 


procedure VALIDATE DATA (THE GRAPH : in out DIGRAPH.GRAPH) ; 


CRIT _OP_LACKS MET >: exception; 
MET NOT _LESS_ THAN PERIOD >; exception; 
MET NOT LESS THAN MRT : exception; 
MCP _NOT LESS THAN MRT > exception; 
MCP_LESS_THAN MET : exception; 
MET IS GREATER THAN FINISH WITHIN : exception; é 
SPORADIC OP_LACKS MCP > exception; 
SPORADIC OP LACKS MRT : exception; 
PERIOD LESS THAN FINISH WITHIN ; exception; 


end FILE PROCESSOR; 
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APPENDIX U STATIC SCHEDULER FILE PROCESSOR 


ee ee SSeS SS |S |S SS SPS SP SS SPS SS SS SF SPS SP SP SVS SOS SF OSPF SF SF SF SF FP FB SF SOF FTI SVWSTWO SEIMEI SF SVE SS SS S&S S&S SS @&S Ss os 


-- file: 
-- author: 


-- date: 
-- modified: 


fp b.a 


laura marlowe 
murat kilic 


oct 89 


dec 89 by laura j. white 


apewe= @ op © op OP eo eo 6 2 eo eo! 6 2 6] SS op So & oe oe So So SO! C!S SS SE eo ow eo ow ow ow! SE eS SS SE SE SE SP SP SE SP SP Ge Ge Gm GS SE GS SP Se Se Ss ae Ss Ge Gs Gs as a 


with TEXT IO 
with FILES; 


e 
ce 


use FILES; 


package body FILE PROCESSOR is 


procedure SEPARATE DATA (THE GRAPH : in out DIGRAPH.GRAPH) is 


-- This procedure reads the output file which has the link 

-- information with the Atomic operators and depending upon 

-- the keywords that are declared as constants separates the 

-- information in the file and stores it in the graph data 
ture, where GRAPH has the operator and link information 


a= SCLrUC 
-- in it 


package 


MET 
MRT 
MCP 
PERIOD 
WITHIN 
LINK 
ATOMIC 
EMPTY 


VALUE_IO is new TEXT_I0O.INTEGER_IO (VALUE) ; 


constant 
constant 
constant 
constant 
constant 
constant 
constant 
constant 


Current Value : 


New _ Stre 
New Word 
Cur Opt 

Cur_ Link 


NON CRIT 
AG_OUTFI 
INPUT 
OUTPUT 


am : 


S 
LE 


VARSTRING. VSTRING 
VARSTRING .VSTRING 
VARSTRING.VSTRING 
VARSTRING.VSTRING 
VARSTRING. VSTRING 
VARSTRING.VSTRING 
VARSTRING.VSTRING 
VARSTRING.VSTRING 


VALUB; 


DIGRAPH.DATA_ STREAM; 


VARSTRING. VSTRING; 


OPERATOR; 


DIGRAPH. LINK DATA; 


TEXT IO.FILE TYPE; 
TEXT IO.FILE_TYPE; 
TEXT IO.FILE MODE := TEXT_IO.IN FILE; 
TEXT IO.FILE MODE := 
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VARSTRING.VSTR ("MET") ; 
VARSTRING.VSTR ("MRT") ; 
VARSTRING.VSTR ("MCP") ; 
VARSTRING.VSTR ("PERIOD") ; 
VARSTRING. VSTR ("WITHIN") ; 
VARSTRING.VSTR ("LINK") ; 
VARSTRING.VSTR ("ATOMIC") ; 
VARSTRING. VSTR ("EMPTY") ; 


TEXT IO.OUT FILE; 


PRINT EDGES ; DIGRAPH EB LIsts- Lisi; 


S12 6S2 ele : DIGRAPH.V_LISTS.LIST; ( 
ID1, Ep : OPERATOR; 
START NODE > OPERATOR; 
END NODE > OPERATOR; 


procedure INITIALIZE OPERATOR (OP : in out OPERATOR) is 
begin 
OP .THE MET := 
OP.THE MRT 
OP .THE MCP 
OP.THE PERIOD : 
OP .THE WITHIN 
end; 


i ou oa 
oS © ere] 


™“e 





begin 
TEXT IO.OPEN (AG OUTFILE, INPUT, "/n/suns2/work/caps/prototypes/atomic. info 
TEXT _IO.CREATE (NON _CRITS, OUTPUT, "/n/suns2/work/caps/prototypes/non_crits" 
VARSTRING.GET LINE (AG OUTFILE, New Word) ; 
while not TEXT IO.END OF FILE(AG OUTFILE) loop 


if VARSTRING.EQUAL (New Word, LINK) then 


START NODE.THE OPERATOR_ID := EMPTY; 
END NODE.THE OPERATOR ID := EMPTY; 
DIGRAPH.V_STRING.GET LINE (AG_OUTFILE,New Stream) ; 

Cur Link.THE DATA STREAM := New Stream; 
VARSTRING.GET LINE(AG OUTFILE, New Word) ; | 
L1 := THE GRAPH. VERTICES; ‘ 


while DIGRAPH.V_LISTS.NON_EMPTY(L1) loop 
if VARSTRING. EQUAL (DIGRAPH.V_LISTS.VALUE (L1) .THE_OPERATOR_ID, New _Wo 


th 
START NODE := DIGRAPH.V_LISTS.VALUE (L1) ; 
exit; 
end if; 
DIGRAPH.V_ LISTS.NEXT(L1); 
end loop; 


VALUE_IO.GET(AG OUTFILE, Current Value); 
TEXT _IO.SKIP_LINE(AG OUTFILE) ; 


Cur Link THE LINK MET 2 = Gi emery oer 
VARSTRING.GET LINE (AG OUTFILE, New Word) ; 
Ll := THE GRAPH.VERTICES; 


while DIGRAPH.V_LISTS.NON_EMPTY(L1) loop 
if VARSTRING. EQUAL (DIGRAPH.V_LISTS.VALUE (L1) .THE OPERATOR_ID,New Wo’ 
thi 


END NODE := DIGRAPH.V_LISTS.VALUE (L1) ; 
exit; 
end if; 
DIGRAPH.V_LISTS.NEXT(L1) ; 
end loop; 


-- when either starting node or ending node of a link is 


300 


-- EXTERNAL, the link information will not be added to the 


-- graph. Assuming that all external data coming in is ready 
-- at start time. 


hog VARSTRING.NOTEQUAL (START_NODE.THE OPERATOR_ID, EMPTY) and 
VARSTRING.NOTEQUAL (END_NODE.THE OPERATOR_ID,EMPTY) then 
DIGRAPH.V_LISTS.ADD (START_NODE, Cur_Link.THE FIRST OP ID); 
DIGRAPH.V_LISTS.ADD (END NODE, Cur_Link.THE SECOND OP_ID); 
DIGRAPH.ADD (Cur Link, THE GRAPH) ; 
end if; 
VARSTRING.GET LINE ( AG OUTFILE, New Word); 


elsif VARSTRING.EQUAL (New _Word,ATOMIC) then 
VARSTRING.GET LINE ( AG OUTFILE, New Word); 
Cur Opt.THE OPERATOR_ID := New Word; 
VARSTRING.GET LINE (AG OUTFILE, New Word) ; 
if (VARSTRING. EQUAL (New Word, ATOMIC)) or 
(VARSTRING.EQUAL (New Word, LINK)) or 
(TEXT _IO.END OF FILE(AG OUTFILE)) then 
VARSTRING. PUT _LINE(NON CRITS, Cur_Opt.THE_OPERATOR_ID); 
else 
while VARSTRING. NOTEQUAL (New Word, ATOMIC) and 
VARSTRING.NOTEQUAL (New Word, LINK) and 
not TEXT _IO.END OF FILE(AG_OUTFILE) loop 


if VARSTRING.EQUAL (New Word,MET) then 
VALUE _IO.GET(AG OUTFILE,Current_Value) ; 
TEXT_IO.SKIP_LINE(AG_ OUTFILE) ; 
Cur Opt.THE MET := Current Value; 


elsif VARSTRING.EQUAL (New Word,MRT) then 
VALUE_IO.GET (AG _OUTFILE,Current_Value) ; 
TEXT _IO.SKIP_LINE(AG_OUTFILE) ; 
Cur Opt.THE MRT:= Current Value; 


elsif VARSTRING.EQUAL (New _Word,MCP) then 
VALUE_IO.GET(AG_OUTFILE, Current_Value) ; 
TEXT_IO.SKIP_LINE(AG OUTFILE) ; 
Cur_Opt.THE MCP := Current_Value; 


elsif VARSTRING. EQUAL (New Word, PERIOD) then 
VALUE_IO.GET(AG OUTFILE, Current_Value) ; 
TEXT _IO.SKIP_LINE (AG OUTFILE) ; 
Cur _Opt.THE PERIOD := Current_Value; 


elsif VARSTRING. EQUAL (New Word, WITHIN) chen 
VALUE _IO.GET(AG_OUTFILE, Current_Value); 
TEXT IO.SKIP_LINE(AG_OUTFILE) ; 
Cur Opt.THE WITHIN >= Current Value; 

end if; 


301 


VARSTRING.GET_ LINE (AG OUTFILE, New_Word) ; 
end loop; 


DIGRAPH.ADD (Cur Opt, THE GRAPH) ; 
INITIALIZE OPERATOR (Cur OPt); 
end if; 
end if; 
end loop; 
end SEPARATE DATA; 


procedure VALIDATE DATA (THE GRAPH : in out DIGRAPH.GRAPH) is 


TARGET : DIGRAPH.V_LISTS.LIST; 

package VAL_IO is new TEXT_IO.INTEGER_IO (VALUE) ; 
begin 

TARGET := THE GRAPH.VERTICES; 

while DIGRAPH.V_LISTS.NON_EMPTY (TARGET) loop 


~~ ensure that there is no operator without an MET. 
lg @ DIGRAPH.V_ LISTS.VALUE (TARGET) .THE MET = Q then 


Exception Operator := DIGRAPH.V_LISTS.VALUE (TARGET) .THE OPERATOR ID; | 


raise CRIT _OP_LACKS MET; 
end if; 


if DIGRAPH.V_LISTS: VALUE (TARGET) (THE PERTOD = 0 then 


-- Check to ensure that MCP has a value for sporadic operators 


if DIGRAPH.V_LISTS.VALUE (TARGET) .THE MCP = 0 then 


Exception Operator := DIGRAPH.V_LISTS.VALUE (TARGET) . THE OPERATOR ]| 


raise SPORADIC OP LACKS MCP; 
elsif DIGRAPH.V_LISTS.VALUE (TARGET) .THE MET > 


DIGRAPH.V_LISTS.VALUE (TARGET) .THE MCP t 


Exception Operator := DIGRAPH.V_LISTS.VALUE (TARGET) . THE OPERATOR_IL 


raise MCP_LESS THAN MET; 
end if; 


-- Check to ensure that MRT has a value for sporadic operators 
if DIGRAPH.V_LISTS.VALUE (TARGET) .THE MRT = 0 then 


Exception Operator := DIGRAPH.V_LISTS.VALUE (TARGET) .THE OPERATOR_IE 


raise SPORADIC OP LACKS MRT; 
end if; 


~~ Check to ensure that the MRT is greater than the MET. 
if DIGRAPH.V_LISTS. VALUE (TARGET) .THE MET > 


| 
| 
| 
4 
| 
| 
: 
: 
| 





| 


DIGRAPH.V_LISTS.VALUE (TARGET) .THE MRT t 
Exception Operator := DIGRAPH.V_LISTS.VALUE (TARGET) . THE OPERATOR_IP 


raise MET NOT _LESS THAN MRT; 
end if; 


-- Guarantees that an operator can fire at least once 
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-- before a response expected. 
if DIGRAPH.V_LISTS.VALUE (TARGET) .THE MCP > 
DIGRAPH.V LISTS.VALUE (TARGET) .THE MRT then 
raise MCP_NOT LESS THAN MRT; 7 = 
end if; 


else 
-- Check to ensure that the PERIOD is greater than the MET. 
lg DIGRAPH.V_LISTS. VALUE (TARGET) . THE MET > 
DIGRAPH.V_LISTS.VALUE (TARGET) .THE PERIOD then 


Exception Operator := DIGRAPH.V_LISTS. VALUE (TARGET) . THE OPERATOR_ID; 
raise MET _NOT_LESS THAN PERIOD; 
end if; 


~~ Check to ensure that the FINISH WITHIN is greater than the MET. 
if DIGRAPH.V_ LISTS.VALUE (TARGET) .THE WITHIN /= 0 then 
if DIGRAPH.V_LISTS.VALUE (TARGET) .THE MET > 
DIGRAPH.V_LISTS.VALUE (TARGET) .THE WITHIN then 
Exception Operator := DIGRAPH.V_LISTS.VALUE (TARGET) .THE_OPERATOR_ID; 
raise MET IS GREATER_THAN FINISH WITHIN; 
elsif DIGRAPH.V LISTS.VALUE (TARGET) .THE_ PERIOD < 
DIGRAPH.V_LISTS.VALUE (TARGET) .THE WITHIN then 
Exception Operator := DIGRAPH.V_LISTS.VALUE (TARGET) . THE OPERATOR_ID; 
raise PERIOD_LESS_THAN FINISH WITHIN; 
end if; 
end if; 


ene af; 
DIGRAPH.V_LISTS.NEXT (TARGET) ; 
end loop; 


end VALIDATE DATA; 


end FILE PROCESSOR; 
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APPENDIX V STATIC SCHEDULER GRAPH STRUCTURE 


—— fre. graphs s.a 

= eit ease Murat kilic 

a isaac mostov 

=S tony davis 

——saate: sep 89 

-- modified: oct 89 by murat kilic 


— = a a a Ge a ee oe a a a a a oe oe FF eo em em ee ee ee em ee ee ee ee ee ee ee ee ee ee ee oe ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee i ee es es 


with SEQUENCES; 
with VSTRINGS; 


generic 
type VERTEX is private; 


package GRAPHS is 


package V_LISTS is new SEQUENCES (VERTEX) ; 
use V_LISTS; 


package V_STRING is new VSTRINGS (80) ; 
use V_STRING; 


subtype DATA_STREAM is VSTRING; 
subtype MET is NATURAL; 


type LINK DATA is 


record 
THE DATA STREAM : DATA STREAM; 
THE FIRST OP ID : Vebists- Uist; 
THE LINK_MET 2 MET 20), 


THE SECOND OP_ID : V_LISTS.LIST; 
end record; 


package E LISTS is new SEQUENCES (LINK DATA) ; 
use E LISTS; 


type GRAPH is 


record 
VERTICES 3 V_ LISTS List; 
LINKS ; B OLSTS-Siot; 


end record; 
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function EQUAL GRAPHS (Gl 


procedure 


EMPTY (G : out GRAPH); 


function IS NODE(X : in VERTEX; 


function IS _LINK(X : in VERTEX; 


procedure 
procedure 
procedure 
procedure 
procedure 


procedure 


procedure 


procedure 
procedure 


end GRAPHS; 


ADD(X : in VERTEX; G 
ADD(L : in LINK_DATA; 
REMOVE (X : in VERTEX; 


REMOVE (X : in VERTEX; 


SCAN NODES(G : in GRAPH; S 


SCAN PARENTS (X : in VERTEX; G 


in 


G 


G3: 


Y 


in GRAPH; G2 : in GRAPH) return BOOLEAN; 


GRAPH) return BOOLEAN; 


in VERTEX; 
in GRAPH) return BOOLEAN; 


out GRAPH) ; 

in out GRAPH) ; 

in out GRAPH) ; 

in VERTEX; G ;: in out GRAPH); 
; in out V_LISTS.LIST) ; 


in GRAPH; 
in out V_LISTS.LIST) ; 


e¢ ce 


S 


SCAN CHILDREN (X : in VERTEX; G : in GRAPH; 


S : in out V_LISTS.LIST); 


DUPLICATE (G1 : in GRAPH; G2 : in out GRAPH); 


T SORT(G : in GRAPH; S 


> in out V_LISTS.LIST) ; 
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APPENDIX W STATIC SCHEDULER GRAPH STRUCTURE 





—— fee graphs b.a 
-- author: murat kilic 

-- isaac mostov 

= tony davis 

-- date: sep 89 

-- modified: oct 69°by mural kilic 


with UNCHECKED DEALLOCATION; 

package body GRAPHS is 
procedure FREE is new UNCHECKED DEALLOCATION(E LISTS.NODE, E LISTS.LIST); 
function EQUAL GRAPHS (G1 : in GRAPH; G2 : in GRAPH) return BOOLEAN is 


function SUB SET(G1 : in GRAPH; G2 : in GRAPH) return BOOLEAN is 


Li : V_LISTS. LIST := Gl VERTICES, 
L2 : E LISTS.LIST := Gl.LINKS; ( 
begin 


if not SUBSEQUENCE(L1, G2.VERTICES) then 
return FALSE; 
end if; 
while NON EMPTY(L2) loop 
if not IS_LINK (VALUE (VALUE (L2) .THE_FIRST_OP_ID), 
VALUE (VALUE (L2) .THE SECOND OP_ID), G2) then 
return FALSE; 
end if; 
NEXT (L2) ; 
end loop; 
return TRUE; 
end SUB _ SET; 
begin | 
-- equal graphs 
return (SUB _SET(G1, G2) and SUB _SET(G2, G1l)); | 
end EQUAL GRAPHS; 





procedure EMPTY(G : out GRAPH) is 
begin 

EMPTY (G.VERTICES) ; 

EMPTY (G.LINKS) ; 
end EMPTY; 
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function IS NODE(X : in VERTEX; G : GRAPH) return BOOLEAN is 
begin 
if LOOK4 (X, G.VERTICES) /= null then 
return TRUE; 
else 
return FALSE; 
end if; 
end IS NODE; 


function IS_LINK(X : in VERTEX; Y : in VERTEX; G : in GRAPH) return BOOLEAN is 
L : E_LISTS.LIST := G.LINKS; 
begin 
while L /= null loop 
if VALUE (VALUE (L) .THE FIRST OP ID) = X and 
VALUE (VALUE (L) . THE SECOND _OP_ID) = Y then 
return TRUE; 
end if; 
L := L.NEXT; 
end loop; 
return FALSE; 
end IS_LINK; 


procedure ADD(X : in VERTEX; G : in out GRAPH) is 
begin 

ADD (X, G.VERTICES) ; 
end ADD; 


procedure ADD(L : in LINK DATA; G : in out GRAPH) is 
begin 
if LOOK4(L.THE FIRST OP_ID.ELEMENT, G.VERTICES) /= null and 
LOOK4 (L.THE SECOND OP_ID.ELEMENT, G.VERTICES) /= null then 


ADD (L, G.LINKS) ; 


end if; 
end ADD; 


procedure REMOVE (X : in VERTEX; G : in out GRAPH) is 
Sv Lists. LIST; 
ieee LISTS LIST; 
PREV : V_LISTS.LIST := null; 
begin 
SCAN CHILDREN(X, G, S); 
while NON EMPTY(S) loop 
REMOVE (X, VALUE(S), G); 
NEXT (S) ; 
end loop; 
SCAN PARENTS (X, G, S); 
while NON _EMPTY(S) loop 
REMOVE (VALUE (S), X, G); 
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NEXT (S) ; 
end loop; 
REMOVE (X, G.VERTICES) ; 
end REMOVE; 


procedure REMOVE(X : in VERTEX; Y : in VERTEX; G : in out GRAPH) is 


L : E LISTS.LIST := G.LINKS; 

PREV : E_LISTS.LIST :=# null; 

TEMP : E LISTS.LIST := null; 
begin 


while NON EMPTY(L) loop 
if VALUE (VALUE (L).THE FIRST OP_ID) = X and 
VALUE (VALUE (L) .THE SECOND OP _ID) = Y¥ then 
TEMP := L; 
NEXT (L) ; 
FREE (TEMP) ; 
if PREV /= null then 
PREV.NEXT := L; 
else 
G.LINKS := L; 
end if; 
else 
PREV ;:= L; 
NEXT (L) ; 
end if; 
end loop; 
end REMOVE; 


procedure SCAN NODES(G : in GRAPH; S : in out V_LISTS.LIST) is 
L : V_LISTS.LIST 7= G. VERTICES; 
begin 
EMPTY (S) ; 
while NON EMPTY(L) loop 
ADD (VALUE(L), S); 
NEXT (L) ; 
end loop; 
end SCAN NODES; 


procedure SCAN PARENTS(X : in VERTEX; G : in GRAPH; 
S°: in out VoebISto. bist) i4 
L : E_LISTS.LIST := G.LINKS; 


begin 
EMPTY (S) ; 
while NON EMPTY(L) loop 
if VALUE (VALUE (L).THE SECOND OP_ID) = X then 
ADD (VALUE (VALUE (L) .THE FIRST OP_ID), SS) 
end if; 
NEXT (L) ; 
end loop; 
end SCAN PARENTS; 
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procedure SCAN _CHILDREN(X : in VERTEX; G : in GRAPH; 
S : in out V_LISTS.LIST) is 
L : E_LISTS.LIST := G.LINKS; 
begin 
EMPTY (S) ; 
while NON _EMPTY(L) loop 
if VALUE (VALUE (L).THE_FIRST_OP_ID) = X then 
ADD (VALUE (VALUE (L) . THE _SECOND_OP LD) =o): 
end if; 7 
NEXT (L) ; 
end loop; 
end SCAN_CHILDREN; 


procedure DUPLICATE(G1 : in GRAPH; G2 : in out GRAPH) is 
begin 

DUPLICATE (G1.VERTICES, G2.VERTICES) ; 

DUPLICATE (G1.LINKS, G2.LINKS) ; 
end DUPLICATE; 


procedure T_SORT(G : in GRAPH; S ; in out V_LISTS.LIST) is 
G1 : GRAPH; 
iu, © : V_LISTS.LIST; 
begin 
EMPTY (T) ; 
DUPLICATE (G, G1); 
SCAN NODES(G1, L); 
while NON _EMPTY(L) loop 
SCAN PARENTS (VALUE (L), Gl, P); 
if not NON _EMPTY(P) then 
ADD (VALUE (L), T); 
REMOVE (VALUE (L), G1); 
SCAN_NODES (G1, L); 
else 
NEXT (L) ; 
end if; 
end loop; 
SCAN NODES (G1, L); 
if NON EMPTY(L) then 
EMPTY (S); 
else 
LIST REVERSE (Ee, S); 
end if; 
Gnd TSSORT; 
end GRAPHS; 
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APPENDIX X STATIC SCHEDULER HARMONIC BLOCK BUILDER 


== fakes hbb_s.a 

== AuLnor ; murat kilic 

== date: sep 89 

-- modified: oct 89 by murat kilic 


with FILES; use FILES; 
package HARMONIC BLOCK_BUILDER is 


procedure CALC PERIODIC EQUIVALENTS 
(OPT LIST : in out DIGRAPH.V_ LISTS. LIsS#),; 


procedure FIND BASE BLOCK 
(PRECEDENCE LIST : in DIGRAPH.V LISTS.LIST; 
BASE BLOCK : out VALUE ); 


procedure FIND BLOCK LENGTH 
(PRECEDENCE LIST : in DIGRAPH.V_LISTS.LIST; 


HARMONIC BLOCK LENGTH : out INTEGER ); 
NO BASE BLOCK ; exception; 
NO OPERATOR_IN LIST > exception; 


MET NOT LESS THAN PERIOD : exception; 


end HARMONIC BLOCK_BUILDER; 
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APPENDIX Y STATIC SCHEDULER HARMONIC BLOCK BUILDER 


file: hbb b.a 
author: murat kilic 
date: sep 89 


modified: oct 89 


with TEXT_IO; 
with FILES; use FILES; 
package body HARMONIC BLOCK BUILDER is 


procedure CALC PERIODIC EQUIVALENTS 


(OPT LIST : in out DIGRAPH.V_LISTS.LIST) is 
V : DIGRAPH.V_LISTS.LIST := OPT_LIST; 
procedure VERIFY_1 (O : in OPERATOR) is 


-- Check to ensure that MRT has a value for sporadic operators 


begin 
dat O.THE MET >= O.THE PERIOD then 
Exception Operator := O.THE_OPERATOR_ID; 
raise MET NOT_LESS THAN PERIOD; 
end if; 


end VERIFY 1; 


procedure CALCULATE NEW PERIOD (O : in out OPERATOR) is 
DIFFERENCE : VALUE; 


package VALUE_IO is new TEXT_IO.INTEGER_IO (VALUE) ; 


begin 
DIFFERENCE := O.THE MRT - O.THE_MET; 
if DIFFERENCE < O.THE MCP then 
O.THE PERIOD := DIFFERENCE; 
else 
O.THE PERIOD := O.THE_ MCP; 
end if; 
TEXT IO.put ("The new PERIOD is => "); 
VALUE_IO.put (0. THE PERIOD) ; 
TEXT _IO.NEW_LINE; 
end CALCULATE _NEW_PERIOD; 
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begin -- main CALC PERIODIC EQUIVALENTS 

while DIGRAPH.V_LISTS.NON_ EMPTY(V) loop 
if DIGRAPH.V_LISTS.VALUE(V) .THE PERIOD = 0 then 

CALCULATE NEW PERIOD (V.ELEMENT) ; 
end if; 
VERIFY_1(DIGRAPH.V_LISTS. VALUE (V) ); 
DIGRAPH.V_ LISTS.NEXT(V); 
end loop; 
end CALC PERIODIC EQUIVALENTS; 


procedure FIND BASE BLOCK (PRECEDENCE LIST : in DIGRAPH.V_LISTS.LIST; 


BASE BLOCK >; Out VALUE ) is 
Peivon >: DIGRAPH.V_LISTS.LIST := PRECEDENCE LIST; 
DIVISOR : VALUE; 
ALTERNATE SEQUENCE : DIGRAPH.V_LISTS.LIST; 


BASE BLOCK SEQUENCE : DIGRAPH.V_LISTS.LIST; 
package VALUE IO is new TEXT_IO.INTEGER IO (VALUE) ; 


function FIND MINIMUM PERIOD (P_LIST : in DIGRAPH.V_LISTS.LIST) 
return VALUE is 
1 Aa DIGRAPH.V_LISTS.LIST := P_ LIST; 
MIN PERIOD : VALUE := QO; 


begin 
if DIGRAPH.V_LISTS.NON_EMPTY(V) then 
MIN PERIOD := DIGRAPH.V_LISTS.VALUE (V) .THE PERIOD; 
DIGRAPH.V_LISTS.NEXT (V) ; 
while DIGRAPH.V_LISTS.NON_EMPTY(V) loop 
if DIGRAPH.V_LISTS.VALUE(V) .THE PERIOD < MIN PERIOD then 


MIN SEERIOD >= DIGRAPH.V_LISTS.VALUE(V) .THE PERIOD; 
end if; 
DIGRAPH.V_LISTS.NEXT (V) ; 
end loop; 
return MIN PERIOD; 
else 
raise NO OPERATOR _IN LIST; 
end if; 


end FIND MINIMUM PERIOD; 


function MODE DIVIDE (THE PERIOD : in VALUE) return VALUE is 
begin 

return (THE PERIOD mod DIVISOR) ; 
end MODE DIVIDE; 


procedure INITIAL PASS (P_LIST : in out DIGRAPH.V_LISTS.LIST; 
BASE BLOCK SEQUENCE : in out DIGRAPH.V_LISTS.LIST; 
ALTERNATE SEQUENCE : in out DIGRAPH.V_LISTS.LIST) is 
ORIG SEQUENCE : DIGRAPH.V_LISTS.LIST := P_LIST; 
OP_FROM_ORG SEQ : OPERATOR; 
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REMAINDER : VALUE; 
THE PERIOD : VALUE; 
begin 
while DIGRAPH.V_LISTS.NON EMPTY (ORIG SEQUENCE) loop 
THE PERIOD := DIGRAPH.V_LISTS. VALUE (ORIG SEQUENCE) .THE PERIOD; 
REMAINDER := MODE DIVIDE (THE PERIOD) ; ul 
OP_FROM ORG SEQ := DIGRAPH.V_ LISTS. VALUE (ORIG SEQUENCE) ; 
if REMAINDER = 0 then n 
DIGRAPH.V_LISTS.ADD (OP FROM ORG SEQ, BASE BLOCK SEQUENCE) ; 
else J 
DIGRAPH.V_LISTS.ADD (OP_FROM ORG SEQ, ALTERNATE SEQUENCE) ; 
end if; 
DIGRAPH.V_LISTS.NEXT (ORIG SEQUENCE) ; 
end loop; 
end INITIAL PASS; 


begin -- main FIND _BASE BLOCK 
DIVISOR := FIND MINIMUM PERIOD (P_ LIST) ; 
INITIAL PASS(P_LIST, BASE_BLOCK_SEQUENCE, ALTERNATE SEQUENCE) ; 
while DIGRAPH.V_LISTS.NON_EMPTY (ALTERNATE SEQUENCE) loop 
if DIVISOR = 1 then 
raise NO BASE BLOCK; 
-- exit and terminate the Static Scheduler 


else 
DIVISOR := DIVISOR - 1; 
ALTERNATE SEQUENCE := null; 


BASE BLOCK_SEQUENCE := null; 
INITIAL PASS(P_LIST, BASE_BLOCK_SEQUENCE, ALTERNATE_SEQUENCE) ; 
end if; 
end loop; 
BASE BLOCK := DIVISOR; 
end FIND BASE BLOCK; 


procedure FIND_BLOCK_LENGTH 
(PRECEDENCE LIST 
HARMONIC BLOCK_LENGTH 


in DIGRAPH.V_LISTS.LIST; 
out INTEGER ) is 


ORIG _ SEQUENCE : DIGRAPH.V_LISTS.LIST := PRECEDENCE LIST; 
NUMBER1 >: VALUE; 


NUMBER2 : VALUE; 
LCM : VALUE; 
GCD : VALUE; 


TARGET NO : VALUE; 


function FIND GCD 
(NUMBER1 : in VALUE; NUMBER2 : in VALUE) 
return VALUE is NEW_GCD : VALUE; 
begin 
while GCD /= 0 loop 
if (NUMBER1 mod GCD = 0) and (NUMBER2 mod GCD = Q) then 
NEW GCD := GCD; 
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return NEW GCD; 
else 
GCD := GCD - 1; 
end if; 
end loop; 
end FIND GCD; 


function FIND LCM (NUMBER1, NUMBER2Z : VALUE) return VALUE is 
begin 
return (NUMBER1 * NUMBER2) / GCD; 
end FIND LCM; 


begin -- main FIND _BLOCK_LENGTH 
if DIGRAPH.V_LISTS.NON EMPTY (ORIG SEQUENCE) then 
NUMBER1 := DIGRAPH.V_LISTS. VALUE (ORIG_SEQUENCE) .THE PERIOD; 


DIGRAPH.V_LISTS.NEXT (ORIG SEQUENCE) ; 
while DIGRAPH.V_LISTS.NON EMPTY (ORIG SEQUENCE) loop 
NUMBER2 := DIGRAPH.V_LISTS.VALUE (ORIG SEQUENCE) .THE PERIOD; 
if NUMBER2 > NUMBER] then 
GCD := NUMBERI1; 
TARGET NO := NUMBER2; 
else 
GCD := NUMBERZ; 
TARGET NO := NUMBER]; 
end if; 
GCD := FIND _GCD(GCD, TARGET NO); 
LCM ;:= FIND _LCM(NUMBERI, NUMBER2Z) ; 
NUMBER1 := LCM; 
DIGRAPH.V_LISTS.NEXT (ORIG SEQUENCE) ; 
end loop; 
HARMONIC BLOCK LENGTH := LCM; 
else 
raise NO OPERATOR _IN LIST; 
end if; 
end FIND BLOCK_LENGTH; 


end HARMONIC_BLOCK_BUILDER; 
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APPENDIX Z STATIC SCHEDULER ALGORITHMS 


-- file: scheduler s.a 
-- author: murat kilic 
-- date: dec 89 


-- modified: dec 89 by laura j. white 


with FILES; use FILES; 
package OPERATOR SCHEDULER is 


procedure TEST DATA 
(INPUT LIST 
HARMONIC BLOCK LENGTH 


procedure SCHEDULE INITIAL SET 
(PRECEDENCE LIST 
THE SCHEDULE INPUTS  : 
HARMONIC BLOCK_LENGTH 
STOP_TIME : 


procedure SCHEDULE REST _OF_BLOCK 
(PRECEDENCE LIST 
THE SCHEDULE _ INPUTS 
HARMONIC BLOCK LENGTH 
STOP_ TIME 


: in DIGRAPH.V_LISTS.LIST; 


procedure SCHEDULE WITH_EARLIEST START 


(THE GRAPH 
AGENDA 
HARMONIC BLOCK_LENGTH 


in 


in 
in 
in 
in 


in 
in 
in 
in 


in 
in 
in 


procedure SCHEDULE WITH_EARLIEST DEADLINE 


(THE GRAPH 
AGENDA 
HARMONIC _BLOCK_LENGTH 


procedure CREATE STATIC SCHEDULE 
(THE GRAPH 
THE SCHEDULE_INPUTS 
HARMONIC _BLOCK_LENGTH 


MISSED DEADLINE : exception; 
OVER_TIME : exception; 
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in 
in 
in 


i 
ot 
i 


INTEGER) ; 


DIGRAPH.V_LISTS.LIST; 

out SCHEDULE INPUTS LIST.LIST; 
INTEGER; 

out INTEGER) ; 


DIGRAPH.V_LISTS.LIST; 

out SCHEDULE INPUTS LIST.LIST; 
INTEGER; 

INTEGER) ; 


DIGRAPH.GRAPH; 
out SCHEDULE INPUTS LIST.LIST; 
INTEGER) ; 


DIGRAPH.GRAPH; 
out SCHEDULE INPUTS LIST.LIST; 
INTEGER) ; 


n DIGRAPH.GRAPH; 
n SCHEDULE_INPUTS LIST.LIST; 
n INTEGER) ; 


MISSED OPERATOR : exception; 


end OPERATOR SCHEDULER; 
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APPENDIX AA STATIC SCHEDULER ALGORITHMS 


-- file: scheduler b.a 
-- author: murat kilic 
-- date: nov 89 


-- modified: dec 89 by laura j. white 


with FILES; use FILES; 
with TEXT 10; 
package body OPERATOR_SCHEDULER is 


procedure TEST DATA (INPUT_LIST : in DIGRAPH.V_LISTS.LIST; 
HARMONIC BLOCK_LENGTH : in INTEGER) is 


procedure CALC_TOTAL TIME (INPUT_LIST : in DIGRAPH.V_LISTS.LIST; 
HARMONIC _BLOCK_LENGTH : in INTEGER) is 
V : DIGRAPH.V_LISTS.LIST := INPUT_LIST; 


TIMES : FLOAT := 0.0; 
OP_TIME : FLOAT := 0.0; 
TOTAL TIME : FLOAT := 0.0; 
PER : OPERATOR; 


BAD TOTAL TIME : exception; 


function CALC_NO_OF_PERIODS (HARMONIC BLOCK LENGTH :; in INTEGER; 
THE PERIOD : in INTEGER) return FLOAT is 
begin 
return FLOAT (HARMONIC BLOCK LENGTH) / FLOAT (THE PERIOD) ; 
end CALC NO OF_ PERIODS; 


function MULTIPLY BY MET (TIMES : in FLOAT; 
THE MET : in VALUE) return FLOAT is 
begin 
return TIMES * FLOAT (THE _MET) ; 
end MULTIPLY BY_MET; 


function ADD TO SUM (OP_TIME : in FLOAT) return FLOAT is 
begin 

return TOTAL TIME + OP_TIME,; 
end ADD TO_SUM; 


begin --main CALC_TOTAL_TIME 


while DIGRAPH.V_LISTS.NON_EMPTY(V) loop 
PER := DIGRAPH.V_LISTS.VALUE (V) ; 


317 


TIMES:= CALC_NO OF PERIODS (HARMONIC_BLOCK_LENGTH , PER.THE PERIOD) ; 
OP TIME := MULTIPLY BY MET (TIMES, DIGRAPH.V_LISTS. VALUE (V) .THE_MET) ; | 
TOTAL TIME := ADD TO SUM (OP_TIME) ; 
if TOTAL TIME > FLOAT(HARMONIC_BLOCK_LENGTH) then 

raise BAD TOTAL TIME; 





else 
DIGRAPH.V_LISTS.NEXT (V) ; 
end if; 
end loop; 
exception 
when BAD TOTAL TIME => | 


TEST VERIFIED := FALSE; 
TEXT IO.PUT("The total execution time of the operators exceeds") ; 
TEXT _IO.PUT_LINE(" the HARMONIC BLOCK_LENGTH") ; 
TEXT IO.NEW_LINE; : 
end CALC TOTAL TIME; 


procedure CALC_HALF PERIODS (INPUT_LIST : in DIGRAPH.V_LISTS.LIST) is 


V : DIGRAPH.V_LISTS.LIST := INPUT_LIST; 
HALF PERIOD : FLOAT; 
FAIL HALF PERIOD : exception; 


function DIVIDE PERIOD BY_2 (THE PERIOD : in VALUE) return FLOAT is 
begin 

return FLOAT(THE PERIOD) / 2.0; 
end DIVIDE PERIOD BY 2; 





begin --main CALC HALF PERIODS; 
while DIGRAPH.V_LISTS.NON EMPTY (V) loop 
HALF PERIOD := DIVIDE_PERIOD_ BY _2(DIGRAPH.V_LISTS.VALUE (V) .THE PERIOD) 
if FLOAT (DIGRAPH.V LISTS.VALUE(V) .THE MET) > HALF PERIOD then 
Exception Operator := DIGRAPH.V_LISTS.VALUE(V) .THE OPERATOR_ID; 
raise FAIL HALF PERIOD; | 
else 
DIGRAPH.V_LISTS.NEXT (V) ; 
end if; 
end loop; 
exception 
when FAIL HALF PERIOD => 
TEST VERIFIED := FALSE; 
oid po Me OPS 20k ("The MET of Operator "); 
VARSTRING.PUT (Exception Operator) ; 
TEXT I0O.PUT LINE (" is greater than half of its period."™); 
end CALC HALF PERIODS; 


procedure CALC RATIO SUM (INPUT LIST : in DIGRAPH.V_LISTS.LIST) is 


V : DIGRAPH.V_LISTS.LIST := INPUT LIST; 
RATIO : FLOAT; 
RATIO SUM : FLOAT := 0.0; 


THE MET : VALUE; 
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THE PERIOD : VALUE; 
RATIO TOO BIG : exception; 


function DIVIDE MET BY PERIOD (THE MET : in VALUE; 
THE PERIOD : in VALUE) return FLOAT is 
begin 
return FLOAT(THE MET) / FLOAT(THE PERIOD); 
end DIVIDE MET BY PERIOD; a 


function ADD TO TIME (RATIO : in FLOAT) return FLOAT is 
begin 

return RATIO SUM + RATIO; 
end ADD TO TIME; 


begin --main CALC RATIO SUM 

while DIGRAPH.V_LISTS.NON EMPTY(V) loop 
THE MET := DIGRAPH.V_LISTS.VALUE(V) .THE MET; 
THE PERIOD := DIGRAPH.V_LISTS.VALUE(V) .THE PERIOD; 
RATIO := DIVIDE MET BY PERIOD (THE MET, THE PERIOD) ; 
RATIO SUM := ADD TO TIME (RATIO); 
DIGRAPH.V_LISTS.NEXT(V) ; 

end loop; 

if RATIO SUM > 0.5 then 
raise RATIO TOO BIG; 


end if; 
exception 
when RATIO TOO BIG => 
TEST VERIFIED := FALSE; 


TEXT _IO.PUT ("The total MET/PERIOD ratio sum of operators is"); 
TEXT _IO.PUT_ LINE (" greater than 0.5"); 
end CALC_RATIO_ SUM; 


begin --main TEST DATA 
CALC _TOTAL TIME(INPUT LIST, HARMONIC BLOCK _ LENGTH) ; 
CALC_HALF PERIODS (INPUT LIST) ; 
CALC_ RATIO SUM(INPUT LIST) ; 
end TEST DATA; 
procedure VERIFY TIME LEFT (HARMONIC BLOCK LENGTH : in INTEGER; 
STOP_TIME : in INTEGER) is 
begin 
if STOP TIME > HARMONIC _BLOCK_LENGTH then 
raise OVER_TIME; 
--exit and terminate the Static Scheduler 
end if; 
end VERIFY TIME LEFT; 
procedure CREATE_INTERVAL (THE OPERATOR :; in OPERATOR; 
INPUT : in out SCHEDULE INPUTS; 
OLD_ LOWER : in VALUE) is 
LOWER BOUND : VALUE; 
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function CALC _LOWER BOUND return VALUE is 

begin 
-- since CREATE_INTERVAL function is used in both SCHEDULE INITIAL SET 
-- and SCHEDULE REST OF BLOCK (OLD LOWER /= 0) check is needed. In 
-- case of the operator is scheduled somewhere in its interval and 
-- (OLD LOWER /= 0), 
-- this check guarantees that the periods will be consistent. : 
i1£ (OLD LOWER /= 0) and (OLD LOWER < INPUT.THE START) then } 





LOWER _ BOUND := OLD LOWER + THE OPERATOR.THE PERIOD; 
else 
LOWER _BOUND = INPUT.THE START + THE OPERATOR.THE PERIOD; 


end if; 
return LOWER_BOUND; 
end CALC_LOWER_BOUND; 


function CALC_UPPER BOUND return VALUE is 
begin 
TE THE OPERATOR. THE WITHIN = 0 then 
return LOWER BOUND SE THE OPERATOR. THE PERIOD = THE OPERATOR. THE MET; 
-- if the operator has a WITHIN constraint, the upper bound of the 
-- interval is reduced. 
else | 
return LOWER_BOUND ts THE OPERATOR. THE WITHIN — THE OPERATOR. THE MET; | 
end if; 
end CALC _UPPER_BOUND; 
begin --main CREATE_INTERVAL 
INPUT.THE LOWER CALC_LOWER_BOUND; 
INPUT’. THESUEPER = CALC_UPPER_BOUND; 
end CREATE INTERVAL; 


procedure SCHEDULE_INITIAL SET 


———— | = 





(PRECEDENCE LIST engl DIGRAPH.V_LISTS.LIST; 

THE SCHEDULE INPUTS : in out SCHEDULE INPUTS LIST.LIST; 
HARMONIC BLOCK LENGTH : in INTEGER; 

STOP_TIME > in out INTEGER) is 


V : DIGRAPH.V_LISTS.LIST := PRECEDENCE LIST; 


START TIME : INTEGER := 0; 
NEW INPUT : SCHEDULE INPUTS; 
OLD LOWER : VALUE :=0; 


begin --SCHEDULE_INITIAL_SET 
while DIGRAPH.V_LISTS.NON EMPTY(V) loop 


Exception Operator := DIGRAPH.V_LISTS.VALUE (V) . THE OPERATOR_ID; 
NEW INPUT.THE OPERATOR := DIGRAPH.V_LISTS.VALUE(V) .THE OPERATOR_ID; 
NEW_INPUT.THE START := START _TIME; 

STOP_TIME := START_TIME + DIGRAPH.V_LISTS.VALUE (V) . THE MET; 

VERIFY TIME LEFT (HARMONIC BLOCK LENGTH, STOP TIME) ; 
NEW_INPUT.THE STOP := STOP TIME; 


START TIME se oTOP TIME; 
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-- for every operator in SCHEDULE INITIAL SET, OLD LOWER is zero. 
-- So we always send zero value to CREATE INTERVAL. 
CREATE _ INTERVAL (DIGRAPH.V_LISTS.VALUE(V), NEW INPUT, OLD LOWER) ; 
SCHEDULE INPUTS LIST.ADD (NEW INPUT, THE SCHEDULE INPUTS) ; 
DIGRAPH.V_LISTS.NEXT (V) ; rag « 
end loop; 
end SCHEDULE INITIAL SET; 
procedure SCHEDULE REST _OF_BLOCK 
(PRECEDENCE _LIST:in DIGRAPH.V_LISTS.LIST; 
THE_SCHEDULE_INPUTS : in out SCHEDULE_INPUTS_LIST.LIST; 
HARMONIC_BLOCK_LENGTH : in INTEGER; 
STOP _TIME : in INTEGER) is 


V : DIGRAPH.V_LISTS.LIST := PRECEDENCE LIST; 

TEMP : SCHEDULE_INPUTS_LIST.LIST := THE SCHEDULE INPUTS; 
V_LIST : DIGRAPH.V_LISTS.LIST; 

P : SCHEDULE INPUTS LIST.LIST; 

S : SCHEDULE_INPUTS LIST.LIST; 

START_TIME : INTEGER := 0; 

INTEGER := STOP TIME; 


TIME STOP : 
NEW_INPUT : SCHEDULE INPUTS; 
OLD LOWER : VALUE; 

begin 


DIGRAPH.V_LISTS.DUPLICATE (PRECEDENCE LIST, V_LIST); 


SCHEDULE INPUTS LIST.LIST_ REVERSE (THE SCHEDULE INPUTS, P); 


Loop 
while SCHEDULE INPUTS LIST.NON EMPTY(P) loop 
if SCHEDULE_INPUTS_LIST.VALUE(P).THE_ LOWER < HARMONIC BLOCK LENGTH then 
NEW _INPUT.THE OPERATOR 7= DIGRAPH.V_LISTS.VALUE (V) . THE _OPERATOR_ID; 
-~ check if the operator can be scheduled in its interval 
if SCHEDULE_INPUTS_LIST.VALU#(P) .THE UPPER - TIME STOP 
>= DIGRAPH.V_LISTS.VALUE(V) .THE MET then 
if SCHEDULE_INPUTS_LIST.VALUE (P) .THE LOWER >= TIME STOP then 
START _ TIME := SCHEDULE INPUTS _LIST.VALUE (P) . THE LOWER; 
else 
START TIME := TIME STOP; 
end if; 
NEW _INPUT.THE START := START _TIME; 
NEW_INPUT.THE STOP := START_TIME + DIGRAPH.V_LISTS.VALUE (V) . THE MET; 
TIME STOP := NEW_INPUT.THE STOP; 
OLD_LOWER := SCHEDULE INPUTS_LIST.VALUE (P) . THE LOWER; 
CREATE INTERVAL (DIGRAPH.V_LISTS.VALUE(V), NEW_INPUT, OLD_LOWER) ; 
SCHEDULE_INPUTS_LIST.ADD (NEW_INPUT, TEMP) ; 
SCHEDULE _INPUTS_LIST.ADD(NEW_INPUT, S); 
Exception Operator := DIGRAPH.V_LISTS.VALUE(V) .THE_OPERATOR_ID; 
VERIFY TIME LEFT (HARMONIC_BLOCK_LENGTH, TIME STOP) ; 
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DIGRAPH.V_LISTS.NEXT (V) ; 
SCHEDULE INPUTS _LIST.NEXT(P) ; | 
-- if the operator can not be scheduled in its interval raise the 


-- exception 
erse { 
Exception Operator := DIGRAPH.V_LISTS.VALUE(V) .THE_OPERATOR_ID; 

raise MISSED DEADLINE; 
end if; 


else 
DIGRAPH.V_LISTS.REMOVE (DIGRAPH.V_LISTS.VALUE(V), V_LIST); 
DIGRAPH.V_LISTS.NEXT (V) ; . 
SCHEDULE INPUTS LIST.NEXT(P) ; 
end if; 

end loop; 

T£ SCHEDULE INPUTS _LIST.NON_EMPTY (S) then 
SCHEDULE INPUTS LIST.LIST_REVERSE(S, P); 
SCHEDULE INPUTS LIST.EMPTY (S) ; : 
V := V_LIST; 

else 
exit; | 

end if; | 
end loop; 
SCHEDULE_INPUTS_LIST.LIST_REVERSE (TEMP, THE SCHEDULE INPUTS) ; 


end SCHEDULE REST OF BLOCK; 
procedure BUILD OP_INFO LIST 
(THE GRAPH >: in DIGRAPH.GRAPH; 
THE OP_INFO LIST : in out OP_INFO LIST.LIST) is 
-- this procedure finds each operator‘s successors and predecessors 
-- first and creates Ehe OPERATOR SINE Oeil. 
V : DIGRAPH.V_LISTS.LIST := THE GRAPH. VERTICES; | 
S : DIGRAPH.V_LISTS.LIST; | 
P : DIGRAPH.V_LISTS.LIST; 
NEW NODE : OP_INFO; 





begin 
while DIGRAPH.V_LISTS.NON_EMPTY(V) loop 
DIGRAPH.SCAN CHILDREN (DIGRAPH.V_LISTS.VALUE(V), THE GRAPH, S); | 
DIGRAPH.SCAN_ PARENTS (DIGRAPH.V_LISTS.VALUE(V), THE GRAPH, P); | 
NEW _NODE.NODE := DIGRAPH.V_LISTS.VALUE (V) ; | 


NEW _NODE.SUCCESSORS := S; : 
NEW_NODE.PREDICESSORS := P; : 


OP_INFO LIST.ADD(NEW NODE, THE OP INFO LIST) ; 
DIGRAPH.V_LISTS.NEXT (V) ; 
end loop; 
end BUILD_OP_INFO LIST; 
procedure PROCESS EST END NODE 
(MAY BE AVAILABLE: in out SCHEDULE _ INPUTS LIST.LIST; 
OPT : in OPERATOR) is 
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—- transfer the OPERATOR record into SCHEDULE INFO record and adds 

-- that into the MAY AVAILABLE LIST for the Earliest Start Scheduling 
-- Algorithm. Initially all the values are zero. 

NEW_NODE : SCHEDULE INPUTS; 


begin 
NEW_NODE.THE OPERATOR := OPT.THE OPERATOR ID; 
SCHEDULE_INPUTS LIST.ADD (NEW NODE, MAY BE AVAILABLE) ; 
end PROCESS EST END NODE;  —. 


procedure PROCESS _EDL END NODE 


(MAY BE AVAILABLE: in out SCHEDULE _ INPUTS _LIST.LIST; 
OPT : in OPERATOR) is 
--transfer the OPERATOR record into SCHEDULE _INFO record and adds that 
--into the MAY AVAILABLE LIST for the Earliest Deadline Scheduling 
-- Algorithm. Initially all the values are zero. 
NEW NODE : SCHEDULE INPUTS; 


begin 
NEW _NODE.THE OPERATOR := OPT.THE OPERATOR ID; 
NEW _NODE.THE_ LOWER := 0; -- we can omit this, because it’s already zero. 


if OPT.THE WITHIN /= 0 then 
NEW _NODE.THE UPPER := OPT.THE WITHIN; 
else 
NEW NODE.THE UPPER := OPT.THE PERIOD; 
end if; 
SCHEDULE INPUTS _LIST.ADD (NEW_NODE, MAY BE AVAILABLE) ; 
end PROCESS_EDL_END_ NODE; 
function FIND _OPERATOR(THE_OP_INFO_ LIST : in OP_INFO LIST.LIST; 
ID : in OPERATOR_ID) 
return OP_INFO LIST.LIST is 
-- finds the operator that we use currently to get the required information. 
TEMP : OP_INFO LIST.LIST := THE_OP_INFO LIST; 


-- assumed that it’s guaranteed to find an operator. 
begin 
while OP_INFO_LIST.NON_EMPTY(TEMP) loop 
if VARSTRING.EQUAL(OP_INFO LIST.VALUE (TEMP) .NODE.THE OPERATOR ID, ID) then 
return TEMP ; 
end if; 
OP_INFO LIST.NEXT (TEMP) ; 
end loop; 
end FIND OPERATOR; 
function CHECK AGENDA(THE_NODE : in OP_INFO; 
AGENDA in SCHEDULE INPUTS LIST.LIST) 
return BOOLEAN is 
-- checks the AGENDA list to see if all the predecessors of the 
-- operator are in there. 
P : DIGRAPH.V_LISTS.LIST := THE NODE. PREDICESSORS; 
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A : SCHEDULE INPUTS _LIST.LIST := AGENDA; 
OK : BOOLEAN := FALSE; 
begin 





while DIGRAPH.V_LISTS.NON EMPTY (P) loop 
while SCHEDULE_INPUTS_LIST.NON_EMPTY(A) loop | 
if VARSTRING. EQUAL (DIGRAPH.V_LISTS.VALUE (P) . THE _OPERATOR_ID, 
SCHEDULE_INPUTS _LIST.VALUE (A) .THE_OPERATOR) then _ 
OK := TRUE; 
exit; 
end if; 
SCHEDULE_INPUTS_LIST.NEXT (A) ; 
end loop; 
Pe OK enen 
DIGRAPH.V_LISTS.NEXT(P) ; 


A := AGENDA; 
OK := FALSE; 
else 


-- if the pointer reached to the end of the AGENDA, it means the 
-- operator is not in AGENDA, if so return FALSE. 
return OK; 
endedit: | 
end loop; 
-- if the pointer reached to the end of the predecessor list, it 
-- means the operator is in AGENDA. 
OK := TRUE; 
return OK; 
end CHECK AGENDA; 
procedure EST INSERT 
(TARGET See hak SCHEDULE INPUTS; 
MAY BE AVAILABLE : in out SCHEDULE INPUTS _LIST.LIST) is 
-- used to insert the operators into the MAY BE AVAILABLE list to 
-- schedule for the Earliest Start Scheduling Algorithm. 





ee 


PREV a. SCHEDULE _ INPUTS _LIST.LIST >= null; 
at : SCHEDULE INPUTS LIST.LIST := MAY _BE AVAILABLE; 
i 
begin | 


if NOT(SCHEDULE INPUTS LIST.NON_EMPTY(T)) then 
-- when MAY BE AVAILABLE list is empty, add the operator immediately. 
SCHEDULE INPUTS_LIST.ADD (TARGET, MAY BE AVAILABLE) ; 

else 


-- in case the target operator’s EST is smaller than the first operator’ 

-- EST add the operator to the list immediately. 

if TARGET.THE LOWER < SCHEDULE INPUTS _LIST.VALUE (T) .THE LOWER then 
SCHEDULE INPUTS LIST.ADD(TARGET, MAY BE AVAILABLE) ; 


-- in case the operator with the same EST is in the list, do not insert 

-- otherwise; insert the operator in its order. 

elsif NOT(SCHEDULE INPUTS LIST.MEMBER(TARGET, MAY BE AVAILABLE)) then 
while SCHEDULE INPUTS LIST.NON_EMPTY(T) loop 
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ai 2 TARGET.THE LOWER > SCHEDULE INPUTS LIST.VALUE(T) .THE LOWER then 


PREV := T; 

SCHEDULE _ INPUTS _LIST.NEXT(T) ; 
else 

exit; 
end if; 


end loop; 
SCHEDULE INPUTS LIST.ADD (TARGET, 6 ae 
if SCHEDULE _ INPUTS _LIST.NON_EMPTY (PREV) then 
PREV.NEXT := T; 
else 
MAY BE AVAILABLE := T; 
end if; 
end if; 
end if; 
end EST_INSERT; 
procedure EDL INSERT 
(TARGET >: in SCHEDULE INPUTS; 
MAY BE AVAILABLE : in out SCHEDULE_INPUTS LIST.LIST) is 


-- used to insert the operators into the MAY BE AVAILABLE list to 
-- schedule for the Earliest Deadline Scheduling Algorithm. 

PREV : SCHEDULE INPUTS _LIST.LIST := null; 

T : SCHEDULE_INPUTS LIST.LIST := MAY BE AVAILABLE; 


begin 
if NOT (SCHEDULE INPUTS LIST.NON EMPTY(T)) then 
SCHEDULE _INPUTS_LIST.ADD (TARGET, MAY BE AVAILABLE) ; 
else 
if TARGET.THE UPPER < SCHEDULE_INPUTS_LIST.VALUE(T) .THE UPPER then 
SCHEDULE INPUTS _LIST.ADD(TARGET, MAY BE AVAILABLE) ; 
elsif NOT (SCHEDULE_INPUTS_LIST.MEMBER(TARGET, MAY BE AVAILABLE)) then 
while SCHEDULE_INPUTS LIST.NON_EMPTY(T) loop 
if TARGET.THE UPPER > SCHEDULE INPUTS _LIST.VALUE(T) .THE UPPER then 


PREV := T; 
SCHEDULE INPUTS LIST.NEXT (T) ; 
else 
exit; 
end if; 


end loop; 
SCHEDULE _INPUTS LIST.ADD (TARGET, Tis 
if SCHEDULE INPUTS LIST.NON_EMPTY (PREV) then 
PREV.NEXT ;:= T; 
else 
MAY BE AVAILABLE := T; 
end if; 
end if; 
end if; 
end EDL INSERT; 


function OPERATOR_IN LIST(OPT_ID : in OPERATOR_ID; 
IN List : in SCHEDULE INPUTS LIST.LIST) 
return BOOLEAN is 

-- this is used to check if the operators in successors list are 

~~ already in the complete MAY BE AVAILABLE list for both EST and 

-- EDL algorithms. 

TEMP : OPERATOR_ID; q 

L : SCHEDULE INPUTS LIST LIST (= sith eile, 


begin 
while SCHEDULE INPUTS LIST.NON_EMPTY (L) loop 

TEMP := SCHEDULE INPUTS_LIST.VALUE(L) .THE_OPERATOR; 

if VARSTRING.EQUAL (TEMP, OPT_ID) then 
return TRUE; 

else 
SCHEDULE INPUTS_LIST.NEXT (L) ; 

end if; 

end loop; 
return FALSE; 
end OPERATOR_IN_ LIST; 
procedure EST _INSERT_SUCCESSORS_OF_OPT 
(THE NODE : in OP _INEO; . 
STOP” Tihs > in VALUE; 
MAY BE AVAILABLE : in out SCHEDULE_INPUTS LIST.LIST) is 
-- inserts the successors of the selected operator into | 
-- MAY BE AVAILABLE list in their orders if they do not 
-- exist in the list. 
S > DIGRAPH.V_LISTS.LIST := THE NODE.SUCCESSORS; 
T : OPERATOR; 
OPT : OPERATOR := THE NODE.NODE; 
TARGET : SCHEDULE INPUTS; 
begin 
while DIGRAPH.V_LISTS.NON EMPTY(S) loop 

T := DIGRAPH.V_LISTS.VALUE (S) ; 

a NOT (OPERATOR_IN LIST(T.THE OPERATOR ID, MAY BE AVAILABLE)) then 
TARGET.THE OPERATOR := DIGRAPH.V_LISTS.VALUE(S) .THE OPERATOR_ID; 
TARGET.THE LOWER := STOP TIME; 

EST INSERT (TARGET, MAY BE AVAILABLE) ; 
end TE: 

DIGRAPH.V_LISTS.NEXT(S); 

end loop; 
end EST_INSERT_SUCCESSORS OF OPT; 


procedure EDL INSERT SUCCESSORS OF OPT 





(THE NODE : in OP_INFO; 
STOP TIME : in VALUE; 
COMPLETE LIST : in out SCHEDULE_INPUTS LIST.LIST; 


MAY BE AVAILABLE : in out SCHEDULE INPUTS LIST.LIST) is 
-- inserts the successors of the selected operator into 
-- MAY BE AVAILABLE list in their orders if they do not exist in 
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-- the list. 

DIGRAPH.V_LISTS.LIST >= THE NODE.SUCCESSORS; 
OPERATOR; = 

OPERATOR := THE NODE.NODE; 

SCHEDULE INPUTS; 


S 
jy 
OPT 
TARGET 
begin 
while DIGRAPH.V_LISTS.NON EMPTY (S) loop 
T := DIGRAPH.V_LISTS.VALUE (S) ; 
if NOT(OPERATOR_IN LIST(T.THE OPERATOR ID, COMPLETE LIST)) then 
TARGET.THE OPERATOR := T.THE OPERATOR ID; a 
TARGET .THE LOWER := STOP TIME; ~ 
-- while we are adding the successors, the deadline of these operators 
-- are calculated by adding either their finish within if exists, or 
-- period to the stop _ time of the last operator. 
if T.THE WITHIN /= 0 then 
TARGET.THE UPPER := STOP_TIME + T.THE WITHIN; 
else 
TARGET.THE UPPER := STOP TIME + T.THE PERIOD; 
end if; 
EDL INSERT (TARGET, MAY BE AVAILABLE) ; 
end if; 
DIGRAPH.V_ LISTS.NEXT(S) ; 
end loop; 
end EDL _INSERT_SUCCESSORS_OF_OPT; 
procedure PROCESS _EST_AGENDA 
(THE OP INFO LIST: in OP_INFO LIST.LIST; 
MAY _ BE AVAILABLE: in out SCHEDULE INPUTS _LIST.LIST; 
AGENDA : in out SCHEDULE INPUTS _LIST.LIST; 
HARMONIC BLOCK_LENGTH : in INTEGER) is 


-- process the MAY BE AVILABLE list to produce AGENDA list which is 
-- used to create a schedule for Earliest Start Scheduling Algorithm. 


V : SCHEDULE INPUTS LIST.LIST := MAY BE AVAILABLE; 
D : SCHEDULE INPUTS_LIST.LIST; 
A : SCHEDULE INPUTS LIST.LIST; 
TEMP : OP_INFO_LIST.LIST; 
TARGET >; SCHEDULE INPUTS; 
NEW_INPUT : SCHEDULE _INPUTS; 
THE NODE : OP_INFO; 
CONTINUE : BOOLEAN; 
STOP_TIME : VALUE := 0; 
OPT : SCHEDULE INPUTS; 
EST : INTEGER; 

begin 


while SCHEDULE INPUTS LIST.VALUE(V) .THE_LOWER < HARMONIC_BLOCK_LENGTH loop 
-- no need to check if all the predicessors are in the AGENDA, because 
-- this is the first node and has no predecessors. 
OPT := SCHEDULE INPUTS LIST.VALUE(V); 
TEMP ;= FIND OPERATOR (THE _OP_INFO_LIST, OPT.THE OPERATOR) ; 
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THE NODE := OP_INFO_LIST.VALUE (TEMP) ; 
if OPT.THE LOWER > 0 then 


CONTINUE := CHECK AGENDA(THE NODE, AGENDA) ; 
else 

CONTINUE := TRUE; 
end if; 


-- if the opt.is not an end node check if all its successors in AGENDA. 
-- if not, select the other operator and repeat the same procedure. | 


while NOT CONTINUE loop 
SCHEDULE INPUTS LIST.NEXT(V) ; 
OPT := SCHEDULE INPUTS LIST.VALUE(V) ; 
TEMP := FIND OPERATOR(THE_OP_INFO_LIST, OPT.THE OPERATOR) ; 
THE NODE := OP_INFO_LIST.VALUE (TEMP) ; 
ate OPT.THE LOWER > Q then 
CONTINUE := CHECK AGENDA(THE NODE, AGENDA) ; 
else 
CONTINUE := TRUE; 
end if; 
end loop; 
TARGET := SCHEDULE INPUTS_LIST.VALUE (V) ; 
SCHEDULE INPUTS LIST.REMOVE (TARGET, MAY BE AVAILABLE) ; 
Exception Operator := TARGET.THE OPERATOR; 
VERIFY TIME LEFT (HARMONIC BLOCK_LENGTH, STOP_TIME) ; 
if TARGET.THE LOWER > STOP_TIME then 
-- zero initially for the first one 


TARGET.THE START = TARGET.THE LOWER; 
else 

TARGET.THE START := STOP_TIME; 
end if; 
STOP_TIME := TARGET.THE START + THE NODE.NODE.THE MET; 
TARGET.THE STOP := STOP _TIME; 
SCHEDULE INPUTS LIST.ADD(TARGET, AGENDA) ; 
EST := TARGET.THE START + THE NODE.NODE.THE PERIOD; 


-- if the operator can be scheduled again, put it back into the 
-- MAY BE AVAILABLE list in its order with the new EST. 

NEW INPUT.THE OPERATOR >= TARGET.THE OPERATOR; 

NEW_INPUT.THE LOWER := EST; 

EST INSERT (NEW_INPUT, MAY BE AVAILABLE) ; 





EST INSERT SUCCESSORS_OF OPT(THE NODE, STOP TIME, MAY BE AVAILABLE) ; 


V := MAY_BE AVAILABLE; 
end loop; 
A := AGENDA; 


SCHEDULE _ INPUTS LIST.LIST REVERSE(A, AGENDA) ; 
end PROCESS _EST_AGENDA; 
procedure PROCESS EDL AGENDA 
(THESOPP INFO LISTS an OF INPOSGIST’. LST; 
COMPLETE LIST > in out SCHEDULE_INPUTS LIST.LIST; 
AGENDA > in out SCHEDULE INPUTS _LIST.LIST; 
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HARMONIC _BLOCK_LENGTH : in INTEGER) is 


-- process the MAY BE AVILABLE list to produce AGENDA list which is 
-- used to create a schedule for Earliest Deadline Scheduling Algorithm. 
V > SCHEDULE INPUTS LIST.LIST := COMPLETE LIST; 


TEMP : SCHEDULE INPUTS LIST.LIST := COMPLETE LIST; 
A SCHEDULE_INPUTS LIST.LIST; 
T OP_ INFO LIST.LIST; 


PREV : SCHEDULE INPUTS LIST.LIST := null; 


TARGET SCHEDULE INPUTS; 
NEW_INPUT : SCHEDULE INPUTS; 
THE NODE =: OP_INFO; 
CONTINUE : BOOLEAN; 
STOP_TIME : VALUE := 0; 
OPT : SCHEDULE INPUTS; 
EST : INTEGER; 
begin 


while SCHEDULE INPUTS LIST.NON EMPTY(TEMP) loop 
if SCHEDULE_INPUTS_LIST.VALUE (TEMP) .THE LOWER < HARMONIC _BLOCK_LENGTH then 
-- no need to check if all the predecessors are in the AGENDA 
OPT := SCHEDULE INPUTS LIST.VALUE (V) ; 
T := FIND OPERATOR(THE OP INFO LIST, OPT.THE OPERATOR) ; 
THE NODE := OP_INFO_LIST.VALUE (T) ; 
if OPT.THE LOWER > 0 then 


-- when the earliest start time of the operator is not zero, we 
-- need to check if all the predicessors of the operator are in 
-- AGENDA. No check otherwise. 


CONTINUE := CHECK AGENDA(THE NODE, AGENDA) ; 
else 

CONTINUE := TRUE; 
end if; 


-- if the opt. is not an end node check if all its successors 
-- in AGENDA. if not, select the other operator and repeat 
-- the same procedure. 
while NOT CONTINUE loop 
SCHEDULE _INPUTS_LIST.NEXT (V); 
OPT := SCHEDULE INPUTS LIST.VALUE (V) ; 
T := FIND OPERATOR(THE_OP_INFO LIST, OPT.THE_OPERATOR) ; 
THE NODE := OP_INFO_LIST.VALUE (T) ; 
if OPT.THE LOWER > 0 then 
CONTINUE := CHECK AGENDA(THE NODE, AGENDA) ; 


else 
CONTINUE := TRUE; 
end if; 
end loop; 
TARGET := SCHEDULE_INPUTS_LIST. VALUE (V) ; 


SCHEDULE INPUTS LIST.REMOVE (TARGET, TEMP) ; 
if SCHEDULE _INPUTS_LIST.NON EMPTY (PREV) then 


329 


PREV.NEXT := TEMP; 
else 
COMPLETE LIST := TEMP; 
end if; 
Exception Operator := TARGET.THE OPERATOR; 





VERIFY TIME LEFT (HARMONIC BLOCK_LENGTH, STOP TIME) ; | 
if TARGET.THE LOWER > STOP_TIME then ; 
--zero initially for the first one 
TARGET.THE START TARGET. THE LOWER; 


else 
TARGET.THE START := STOP TIME; 
end if; 
STOP TIME := TARGET.THE START + THE NODE.NODE.THE MET; 
TARGET.THE STOP := STOP TIME; | 
SCHEDULE INPUTS LIST.ADD (TARGET, AGENDA) ; | 
EST := TARGET.THE START + THE NODE.NODE.THE PERIOD; 
NEW _INPUT.THE OPERATOR := TARGET.THE OPERATOR; 
NEW INPUT.THE LOWER := EST; 


if THE NODE.NODE.THE WITHIN /= 0 then 


NEW INPUT.THE UPPER <= EST + THE NODE.NODE.THE WITHIN; 
else , 
NEW INPUT.THE UPPER := EST + THE _NODE.NODE.THE PERIOD; 
end if; 


EDL INSERT (NEW_INPUT, TEMP) ; 


—-- this 1S to keep tuack of the COMPLETES isl erornves 
if SCHEDULE INPUTS LIST.NON_EMPTY (PREV) then 
-- the pointer is pointing a record other than first one. 
PREV.NEXT := TEMP; 
else 
-- the pointer is pointing the first record in the list. | 
COMPLETE LIST := TEMP; , 
end if; 





EDL INSERT SUCCESSORS OF OPT 
(THE NODE, STOP_TIME, COMPLETE LIST, TEMP) ; | 
V 3:= TEMP; 


-- this is to keep track of the COMPLETE LIST pointer 

Bese SCHEDULE INPUTS LIST.NON_EMPTY (PREV) then 
-- the pointer is pointing a record other than first one. 
PREV.NEXT := TEMP; 

else 
-- the pointer is pointing the first record in the list. 
COMPLETE LIST := TEMP; 

end if; 


else 


PREV := TEMP; 
SCHEDULE_INPUTS LIST.NEXT (TEMP) ; | 
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Viov= TEMP; 
end if; 
end loop; 
while SCHEDULE INPUTS LIST.NON_ EMPTY (TEMP) loop 
if not (OPERATOR_IN LIST 
(SCHEDULE_INPUTS_LIST.VALUE (TEMP) . THE OPERATOR, 
AGENDA)) then 
Exception Operator := SCHEDULE INPUTS LIST.VALUE (TEMP) .THE OPERATOR; 
raise MISSED OPERATOR; i 
end if; 
SCHEDILE INPUTS _LIST.NEXT (TEMP) ; 
end loop; 
A := AGENDA; 
SCHEDULE INPUTS LIST.LIST_ REVERSE (A, AGENDA) ; 
end PROCESS EDL AGENDA; 
procedure SCHEDULE WITH EARLIEST START 
(THE GRAPH : in DIGRAPH.GRAPH; 
AGENDA : in out SCHEDULE _INPUTS_LIST.LIST; 
HARMONIC _BLOCK_LENGTH : in INTEGER) is 
-- used to find a feasible schedule for Earliest Start Scheduling Algorithm. 
THE OP INFO LIST : OP_INFO LIST.LIST; 
MAY BE AVAILABLE : SCHEDULE INPUTS LIST.LIST; 
H BL : INTEGER := HARMONIC BLOCK LENGTH; 
Ee OP NPO LIST.LIST; 
P ; OP_INFO; 


begin 
BUILD OP_INFO LIST(THE GRAPH, THE OP _ INFO LIST); 
L := THE OP_INFO LIST; 


-- put all the end nodes, which has no predicessors, into 
-- MAY BE AVAILABLE list 
while OP_INFO LIST.NON_EMPTY(L) loop 
P := OP INFO LIST.VALUE(L); 
if NOT(DIGRAPH.V_LISTS.NON_ EMPTY (P.PREDICESSORS)) then 
PROCESS EST END NODE (MAY BE AVAILABLE, P.NODE); 
end if; 
OP_INFO_LIST.NEXT(L) ; 
end loop; 
PROCESS EST _AGENDA(THE OP_INFO LIST, MAY_BE AVAILABLE, AGENDA, H_B _L); 
end SCHEDULE _WITH_EARLIEST_START; 
procedure SCHEDULE WITH_EARLIEST_DEADLINE 
(THE GRAPH : in DIGRAPH.GRAPH; 
AGENDA : in out SCHEDULE_INPUTS_LIST.LIST; 
HARMONIC _BLOCK_LENGTH : in INTEGER) is 


-- used to find a feasible schedule for Earliest Deadline Scheduling 
-- Algorithm 

THE OP_INFO_ LIST : OP_INFO _LIST.LIST; 

MAY BE AVAILABLE : SCHEDULE_INPUTS_LIST. LIST; 
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L : OP INFO LIST.LIST; 


HBL: INTEGER := HARMONIC BLOCK LENGTH; 
Pas OP_INFO,; 


begin ; 
BUILD OP INFO LIST(THE GRAPH, THE OP_INFO_ LIST); 
L := THE OP_INFO LIST; f 


-- put all the end nodes, which has no predecessors, into ' 
-- MAY BE AVAILABLE list . 
while OP_INFO LIST.NON_ EMPTY(L) loop 

P := OP INFO LIST.VALUE(L) ; 

if NOT (DIGRAPH.V_LISTS.NON_EMPTY (P.PREDICESSORS)) then 

PROCESS EDL END NODE (MAY BE AVAILABLE, P.NODE); 

end if; 

OP_ INFO LIST.NEXT(L) ; 
end loop; 
PROCESS EDL AGENDA(THE OP_INFO LIST, MAY BE AVAILABLE, AGENDA, H_B L); 

end SCHEDULE WITH EARLIEST_DEADLINE; 


procedure CREATE STATIC SCHEDULE (THE GRAPH : in DIGRAPH.GRAPH; ! 
THE SCHEDULE_INPUTS : in SCHEDULE INPUTS LIST.LIST; 

HARMONIC BLOCK LENGTH : in INTEGER) is 

-- creates the static schedule output and prints to "ss.a" file. 


V_LIST : DIGRAPH.V_LISTS.LIST := THE GRAPH. VERTICES; 

S : SCHEDULE INPUTS LIST.LIST := THE SCHEDULE INPUTS; 
SCHEDULE : TEXT_IO.FILE TYPE; | 
OUTPUT : TEXT_IO.FILE MODE := TEXT_IO.OUT_FILE; | 
COUNTER : INTEGER ;:= 1; ' 





package VALUE IO is new TEXT _IO.INTEGER IO(VALUE) ; 
use VALUE 10; 

package INTEGERIO is new TEXT_IO.INTEGER_ IO(INTEGER) ; 
use INTEGERIO; 


begin 
TEXT _IO.CREATE (SCHEDULE, OUTPUT, "/n/suns2/work/caps/prototypes/ss.a"); 
TEXT _IO.PUT_LINE(SCHEDULE, "with TL; use TL;"); 
TEXT_IO.PUT_LINE(SCHEDULE, "with DS PACKAGE; use DS_PACKAGE;") ; : 
TEXT_IO.PUT (SCHEDULE, "with PRIORITY DEPINITions, —-)7 
TEXT _IO.PUT_ LINE (SCHEDULE, “use PRIORITY_DEFINITIONS;") ; | 
TEXT IO.PUT_LINE(SCHEDULE, "with CALENDAR; use CALENDAR;") ; 
TEXT IO.PUT_LINE (SCHEDULE, "with TEXT ]fO; use’ TEXT £0, 9 | 
TEXT IO.PUT_LINE (SCHEDULE, "procedure STATIC SCHEDULE is") ; | 
| 


while DIGRAPH.V_LISTS.NON_EMPTY(V_ LIST) loop 
TEXT_IO.SET_COL(SCHEDULE, 3); 
VARSTRING. PUT (SCHEDULE, DIGRAPH.V_LISTS.VALUE (V_LIST) .THE_OPERATOR_ID); — 
TEXT _IO.PUT_LINE(SCHEDULE, " TIMING ERROR : exception;"); | 
DIGRAPH.V_LISTS.NEXT (V_LIST) ; 

end loop; 
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TEXT IO.SET COL(SCHEDULE, 3); 
TEXT I0.PUT LINE (SCHEDULE, "task SCHEDULE is"); 
TEXT_IO.SET_COL(SCHEDULE, 5); 
TEXT IO.PUT_ LINE (SCHEDULE, "pragma priority (STATIC SCHEDULE PRIORITY) ;"); 
TEXT_IO.SET_COL(SCHEDULE, 3); 
TEXT _IO.PUT_LINE (SCHEDULE, "end SCHEDULE;") ; 
TEXT IO.NEW LINE (SCHEDULE) ; 
TEXT_IO.SET_COL(SCHEDULE, 3); 
TEXT_IO.PUT_LINE(SCHEDULE, "task body SCHEDULE is"); 
TEXT IO.PUT(SCHEDULE, " PERIOD : constant := "); 
INTEGERIO.PUT (SCHEDULE, HARMONIC _BLOCK LENGTH, 1); 
TEXT IO.PUT LINE (SCHEDULE, ";"); 
S := THE SCHEDULE INPUTS; 
while SCHEDULE_INPUTS_LIST.NON_EMPTY(S) loop 
TEXT IO.SET COL(SCHEDULE, 5); 
VARSTRING.PUT (SCHEDULE, SCHEDULE _ INPUTS _LIST.VALUE (S) . THE OPERATOR) ; 
TEXT _IO.PUT (SCHEDULE, "_STOP_TIME") ; 
INTEGERIO.PUT (SCHEDULE, COUNTER, 1); 
TEXT IO.PUT(SCHEDULE, " ; constant := "); 
VALUE_IO.PUT (SCHEDULE, SCHEDULE _INPUTS_LIST.VALUE(S) .THE STOP, 1); 
TEXT IO.PUT_ LINE (SCHEDULE, 7 
SCHEDULE _INPUTS_ LIST.NEXT(S) ; 
COUNTER := COUNTER + 1; 
end loop; 
TEXT_IO.SET_COL(SCHEDULE, 5); 
TEXT _IO.PUT LINE (SCHEDULE, “SLACK TIME : duration;"); 
TEXT _IO.SET_COL(SCHEDULE, 5); 
TEXT_IO.PUT_LINE (SCHEDULE, "START OF PERIOD : time := clock;"); 
TEXT _IO.PUT_LINE(SCHEDULE, "begin") ; 
TEXT_I0O.PUT_LINE (SCHEDULE, .OOp.) ; 
TEXT_IO.SET_COL(SCHEDULE, 5); 
TEXT IO.PUT (SCHEDULE, "begin"); 


S := THE SCHEDULE_INPUTS; 
COUNTER := 1; 
while SCHEDULE_INPUTS_LIST.NON_EMPTY(S) loop 
TEXT IO.SET COL(SCHEDULE, 7); 
VARSTRING.PUT (SCHEDULE, SCHEDULE_INPUTS_LIST.VALUE(S) .THE OPERATOR) ; 
TEXT IO.PUT LINE (SCHEDULE, ";"); 
TEXT IO.SET COL(SCHEDULE, 7); 
TEXT IO.PUT(SCHEDULE, "SLACK_TIME := START_OF PERIOD + "); 
VARSTRING.PUT (SCHEDULE, SCHEDULE_INPUTS_LIST.VALUE(S) . THE OPERATOR) ; 
TEXT IO.PUT(SCHEDULE, " STOP_TIME") ; 
INTEGERIO.PUT (SCHEDULE, COUNTER, 1) ; 
TEXT IO.PUT LINE (SCHEDULE, " - CLOCK;"); 
TEXT IO.SET COL(SCHEDULE, 7); 
TEXT IO.PUT LINE(SCHEDULE, "if SLACK_TIME >= 0.0 then"); 
TEXT IO.SET COL(SCHEDULE, 9); 
TEXT IO.PUT LINE(SCHEDULE, "delay (SLACK_TIME) ;"); 
TEXT IO.SET COL(SCHEDULE, 7); 
TEXT IO.PUT LINE (SCHEDULE, "else"); 
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TEXT IO.SET_COL(SCHEDULE, 9); 
TEXT IO.PUT(SCHEDULE, "raise "); 
VARSTRING.PUT (SCHEDULE, SCHEDULE_INPUTS_LIST.VALUE (S) . THE_OPERATOR) ; 
TEXT IO.PUT_LINE (SCHEDULE, " TIMING ERROR; ") ; 
TEXT IO.SET_COL (SCHEDULE, 7"; 
TEXT IO.PUT_LINE(SCHEDULE, "end if;"); 
SCHEDULE INPUTS _ LIST.NEXT(S) ; 
if SCHEDULE_INPUTS LIST.NON_ EMPTY(S) then 
-- pointer is pointing to the next record after this. 
TEXT IO.SET_COL(SCHEDULE, 7); 
TEXT IO.PUT(SCHEDULE, "delay (START_OF PERIOD + "); 
VALUE _IO.PUT (SCHEDULE, SCHEDULE_INPUTS_LIST.VALUE (S) .THE START, L)e 
TEXT _IO.PUT_LINE (SCHEDULE, "=  CLOGIoe ") ; 
TEXT_IO.NEW_LINE (SCHEDULE) ; 
end if; 
COUNTER := COUNTER + 1; 
end loop; 


TEXT IO.SET COL (SCHEDULE, fa 


TEXT IO,PUT LINE(SCHEDULE, "START_OF_PERIOD := START OF PERIOD + PERIOD;")' 


TEXT IO.SET COL(SCHEDULE, 7); 
TEXT IO.PUT_LINE(SCHEDULE, "delay (START_OF_PERIOD - clock) ;"); 


TEXT IO.SET_COL(SCHEDULE, 7); 
TEXT _IO.PUT_LINE (SCHEDULE, "exception") ; 
V_LIST := THE GRAPH.VERTICES; 


TEXT IO.SET COL(SCHEDULE, 9); 





| 
| 
i 


while DIGRAPH.V_LISTS.NON EMPTY (V_LIST) loop ( 


TEXT _IO.PUT(SCHEDULE, “when ") ; 
VARSTRING. PUT (SCHEDULE, DIGRAPH.V_LISTS.VALUE(V_LIST) .THE OPERATOR_ID); 
TEXT _IO.PUT_LINE (SCHEDULE, "TIMING ERROR =>) > 
TEXT _IO.SET_COL (SCHEDULE, 1) 
TEXT _IO.PUT (SCHEDULE, "PUT_LINE(""timing error from operator "); 
VARSTRING. PUT (SCHEDULE, DIGRAPH.V_LISTS.VALUE (V_LIST) .THE OPERATOR_ID); 
TEXT IO.PUT_LINE (SCHEDULE, aah Mel fey 
TEXT _IO.SET_COL(SCHEDULE, 11); 
TEXT _IO.PUT_LINE (SCHEDULE, "START _OF_ PERIOD := clock;"); 
DIGRAPH.V LISTS.NEXT(V_LIST) ; 
end loop; 


TEXT_IO.SET_COL(SCHEDULE, 7); 
TEXT_IO.PUT_LINE (SCHEDULE, “end;") ; 
TEXT_IO.SET_COL(SCHEDULE, 5); 

TEXT _IO.PUT_LINE (SCHEDULE, "end loop;"); 
TEXT_IO.SET_COL(SCHEDULE, 3); 
TEXT_IO.PUT_LINE(SCHEDULE, "end SCHEDULE; ") ; 
TEXT _IO.NEW_LINE (SCHEDULE) ; 

TEXT _IO.PUT_LINE(SCHEDULE, “begin") ; 
TEXT_IO.SET_COL(SCHEDULE, 3); 

TEXT IO.PUT LINE(SCHEDULE, "null;"); 

TEXT _IO.PUT_LINE(SCHEDULE, "end STATIC_SCHEDULE;") ; 
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end CREATE STATIC SCHEDULE; 


end OPERATOR_SCHEDULER; 
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APPENDIX AB STATIC SCHEDULER LIST STRUCTURE 


eee dd 


= (eater sequence s.a 

=— author. murat kilic 

a isaac mostov 

== tony davis 

-- date: sep 89 

-- modified: oct 89 by murat kilic 


generic 
type ITEM is private; 


package SEQUENCES is 
type NODE; 


type LIST is access NODE; 
type NODE is 


record 
ELEMENT : ITEM; 
NEXT * Vigbo lr 


end record; 
BAD VALUE : exception; 
function EQUAL(L1 : in LIST; L2 : in LIST) return BOOLEAN; 
procedure EMPTY(L : out LIST); 


function NON EMPTY(L : in LIST) return BOOLEAN; 


function SUBSEQUENCE(L1 : in LIST; L2 : in LIST) return BOOLEAN; 


function MEMBER(X : in ITEM; L : in LIST) return BOOLEAN; 
procedure ADD(X : in ITEM; L : in out LIST); 

procedure REMOVE(X : in ITEM; L : in out LIST); 

procedure LIST REVERSE(E) >in blot, 2a Out bist), 
procedure DUPLICATE(L1 : in LIST; L2 : in out LIST); 


function LOOK4(X : in ITEM; L : in LIST) return LIST; 
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procedure NEXT(L : in out LIST); 
function VALUE(L : in LIST) return ITEM; 


end SEQUENCES; 
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APPENDIX AC STATIC SCHEDULER LIST STRUCTURE 


. 
. 


ee sequence b.a 

-- author: murat kilic 

-- isaac mostov 

= tony davis 

== date: sep 89 

-- modified: oct 89 by murat kilic 


with UNCHECKED DEALLOCATION; 
package body SEQUENCES is 
procedure FREE is new UNCHECKED DEALLOCATION (NODE, LIST); 


function NON_EMPTY(L : in LIST) return BOOLEAN is 
begin 
if L = null then 
return FALSE; 
else 
return TRUE; 
end if; 
end NON_ EMPTY; 


procedure NEXT(L : in out LIST) is 


begin 
if L /= null then 
L := L.NEXT; 
end if; 
end NEXT; 


function LOOK4(X : in ITEM; L : in LIST) return LIST is 
LL Ss LIST) =. 
begin 
while NON_ EMPTY (L1) loop 
if L1.ELEMENT = X then 
return Li; 
end if; 
NEXT (L1) ; 
end loop; 
return null; 
end LOOK4; 
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procedure ADD(X : in ITEM; L : in out LIST) is 
-- ITEM IS ADDED TO THE HEAD OF THE LIST 
T : LIST := new NODE; 
begin 
T.ELEMENT := X; 
T.NEXT := L; 
L := T; 
end ADD; 


function SUBSEQUENCE(L1 : in LIST; L2 : in LIST) 
L : LIST := LI; 
begin 
while NON EMPTY(L) loop 
if not MEMBER(VALUE(L), L2) then 
return FALSE; 
end if; 
NEXT (L) ; 
end loop; 
return TRUE; 
end SUBSEQUENCE; 


return BOOLEAN is 


function EQUAL(L1 : in LIST; L2 : in LIST) return BOOLEAN is 


begin 


return (SUBSEQUENCE(L1, L2) and SUBSEQUENCE(L2, L1)); 


end EQUAL; 


procedure EMPTY(L : out LIST) is 
begin 

L := null; 
end EMPTY; 


function MEMBER(X : in ITEM; L : in LIST) return BOOLEAN is 


begin 
if LOOK4(X, L) /= null then 
return TRUE; 
else 
return FALSE; 
end if; 
end MEMBER; 


procedure REMOVE(X : in ITEM; L : in out LIST) 1s 


CURR : LIST := L; 
PREV : LIST := null; 
TEMP : LIST := null; 
begin 
while NON EMPTY(CURR) loop 
if VALUE(CURR) = X then 
TEMP := CURR; 
NEXT (CURR) ; 
FREE (TEMP) ; 
if PREV /= null then 
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PREV.NEXT := CURR; 


else 
Lo = CURR, 
end if; 
else 
PREV := CURR; 
NEXT (CURR) ; 
end if; 


end loop; 
end REMOVE; 


procedure LIST REVERSE (L1 
Le: LIiSt := er 
begin 
EMPTY (L2); 
while NON _EMPTY(L) loop 
ADD (VALUE (L), L2); 
NEXT (L); 
end loop; 
end LIST REVERSE; 


procedure DUPLICATE(L1 : in LIST; 


TEMP ;: LIST; 
L > LIST =a L1¢ 
begin 
EMPTY (L2) ; 
while NON EMPTY(L) loop 
ADD (VALUE (L), TEMP); 
NEXT (L) ; 
end loop; 
LIST REVERSE (TEMP, PA) Ie 
end DUPLICATE; 


function VALUE (L 
begin 
if NON EMPTY(L) then 
return L.BELEMENT; 
else 
raise BAD VALUE; 
end if; 
end VALUE; 


end SEQUENCES; 


in LIST) 


an List; 


return ITEM is 
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LZ 


L2 


in out LIST) is 


in out LIST) is 





APPENDIX AD STATIC SCHEDULER TOPOLOGICAL SORTER 


aa epi) t sort _s.a 
-- author: murat kilic 
-- date: oct 89 


-- modified: dec 89 by murat kilic 


with FILES;use FILES; 
package TOPOLOGICAL SORTER is 


procedure TOPOLOGICAL SORT 
(G : in DIGRAPH.GRAPH; 
PRECEDENCE LIST : in out DIGRAPH.V_LISTS.LIST) ; 


end TOPOLOGICAL SORTER; 
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== fle: t_sort_b.a 
-- author: murat kilic 
-- date: oct 89 . 


-- modified: nov 89 by murat kilic , 


with TEXT IO; 
with FILES; use FILES; ' 


package body TOPOLOGICAL SORTER is 
-- This package determines the precedence order in which operators must 
--- execute in the final schedule. This information is determined 


-- from the graph. 


procedure TOPOLOGICAL SORT (G: in DIGRAPH.GRAPH; 
PRECEDENCE LIST: in out DIGRAPH.V_LISTS.LIST) is 


-- This procedure determines which operators in the graph must 
-- be executed before another. 


Q : DIGRAPH.V_LISTS.LIST; 





begin | 
DIGRAPH.T SORT (G, PRECEDENCE LIST) ; | 
Q := PRECEDENCE LIST; : 


end TOPOLOGICAL_SORT; 


end TOPOLOGICAL SORTER; 
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APPENDIX AF DYNAMIC SCHEDULER 


po Lite: dynamic scheduler.a 
-- author: frank palazzo 
-- date: dec 89 


-- modified: dec 89 by laura j. white 


with TEXT_1I10; use TEXT_IO; 
procedure DYNAMIC SCHEDULER is 


NON CRITS : FILE _TYPE; 

DSV3 : FILE TYPE; 

IN STRING : STRING(1..72); 

LAST : NATURAL; 
begin 


OPEN (NON_CRITS, IN_FILE, "/n/suns2/work/caps/prototypes/non crits"); 
CREATE (DSV3, OUT_FILE, "/n/suns2/work/caps/prototypes/ds.a") ; 
PUT LINE (DSV3, "with TL; use TL;"); 
PUT _LINE(DSV3, “package DS_PACKAGE is"); 
PUT LINE (DSV3, " task DYNAMIC SCHEDULE is™)i; 
-- system defined priority for dynamic schedule 
PUT LINE(DSV3, " pragma priority (1);"); 
PUT LINE (DSV3, * end DYNAMIC SCHEDULE; ") ; 
PUT LINE(DSV3, "end DS_PACKAGE;"); 
NEW_LINE (DSV3) 
PUT LINE(DSV3, "package body DS_PACKAGE is); 
PUT LINE (DSV3, " task body DYNAMIC SCHEDULE oe); 
PUT _LINE(DSV3, " begin"); 
PUT LINE(DSV3, " delay (1.0);"); 
while not END OF FILE(NON_CRITS) loop 
begin 

GET_LINE(NON_CRITS, IN_STRING, LAST); 

PUT (DSV3, " ™) ; 

for INDEX in 1..LAST loop 

PUT (DSV3, IN STRING (INDEX) ); 
end loop; 
PUT LINE(DSV3, ";"); 
end; 
end loop; 
PUT _LINE(DSV3, " end DYNAMIC SCHEDULE; ") ; 
PUT LINE (DSV3, “end DS_PACKAGE;"); 
end DYNAMIC SCHEDULER; 


=e 
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